【问题标题】:Large scale pyramid application with multiple databases [closed]具有多个数据库的大型金字塔应用程序[关闭]
【发布时间】:2020-10-17 15:48:19
【问题描述】:

这不是一个问题,而是一个“我的思路是否正确?”主题。

我有一个使用 Pyramid 编写的相当大规模的应用程序的想法,使用多个数据库,并想发表一些我的想法,看看我的想法是否可行。我正在设计应用程序,但还没有开始编写任何代码,以测试它是否可以工作。

我正在考虑扩大规模,因为我预计数据库会显着增长。

要点:

  • 主路由采用www.domain.com/[name]/whatever 的形式,其中[name] 是决定向客户端呈现哪些数据的关键参数。
  • 将有多个数据库:1 个数据库,比如说 site.db,其中包含站点范围的信息和配置,其余的数据库将是 [name].db,其中包含每个人的用户特定数据。这是我预计大部分扩展发生的地方,因为我希望将应用程序设计为接受 100 个数据库,每个用户一个,以划分数据并防止数据交叉污染。

选项:

  1. 2 个数据库。 site.db 和 userdata.db。我将使用相同的数据库模型,但表名将使用 [name] 参数动态确定,例如:[name]_table1、[name]_table2 等,其中 table1/2/n 比那。从某种意义上说,这可能更简单,因为我只有 2 个数据库会话可以使用,并且只要我将会话分开,我应该能够单独查询每个会话。缺点是 userdata.db 可能会随着 100 多个用户而变大。理论上,如果我可以使用 [name] 参数查询正确的表,应该不成问题。

  2. 1 + n 个数据库。管理数据库会话在这里可能很痛苦,但一种可能的解决方案可能是扫描文件夹中的所有 .db 文件,并为每个数据库创建一个会话,并构建一个会话字典,其中字典键是文件名. session['site'] 之类的东西指向处理站点范围数据的 DB 会话,而 session['name'] 指向操纵 name.db 的会话——如果这有意义的话。这样,我可以在路由中使用 [name] 参数来使用适当的数据库会话。


除了上述之外,还将有一个子应用程序,以 IRC 机器人的形式,将监视聊天事件和操作相同数据库的命令。我在想一种方法是运行 IRC bot 的实例,将 [name] 作为参数传入,这样 IRC bot 的每个实例都只能访问一个数据库。 IRC bot 和 Pyramid 应用程序仍有可能尝试操作同一个数据库,这可能会出现问题。也许解决这个问题的一种方法是让 IRC 机器人导入数据库会话(如上面第 2 点所述),并在 IRC 机器人应用程序中使用相同的会话(这会利用 Pyramid 的事务管理器吗?大概是的)。


这就是我现在所拥有的。我希望我正确地考虑了这一点。有什么我大错特错的吗?

【问题讨论】:

    标签: python sqlalchemy pyramid


    【解决方案1】:

    您的问题有很多要解开的内容,对于 SO 来说可能太多了,但我有几个 cmets。

    • 我强烈建议避免使用每个租户模式来动态命名表。所以我会避免选项 1。会话管理总是很困难,并且在某种程度上取决于您选择的数据库(例如,pgbouncer 可以通过保持对许多数据库的持久连接打开而不会使您的代码过于复杂)来提供很大帮助。

    • 操作同一个数据库并不是世界末日——任何体面的数据库都具有并发支持,并且只要您正确处理锁定,就可以处理多个连接。

    • 考虑是否真的值得分离数据库,因为它肯定会预先增加很多复杂性。这取决于问题域和用例是否值得。

    【讨论】:

    • 感谢 cmets。谢谢你的反馈。我绝对可以设计成只使用一个数据库。我想权衡是在拥有一个文件可以变得非常大的单个数据库文件(和一个会话)与拥有 100 个数据库会话之间,每个会话都有一个较小的数据库文件(每个单独的文件不会增长那么大,因为数据是整体数据的一小部分)。
    猜你喜欢
    • 2015-09-17
    • 2015-06-17
    • 2015-08-21
    • 1970-01-01
    • 2023-03-18
    • 1970-01-01
    • 1970-01-01
    • 2010-10-25
    • 2018-02-17
    相关资源
    最近更新 更多