【问题标题】:Individual SQLite Databases per User over MySQL?每个用户在 MySQL 上的单个 SQLite 数据库?
【发布时间】:2012-11-02 13:12:26
【问题描述】:

在这里开始一个新项目,我将存储大量用户数据。我试图从一开始就使系统可扩展,因此我正在考虑将每个用户的数据(本质上是他们存储的文件列表)存储在存储在用户特定目录中的单独 SQLite 数据库中的相当新的想法,而不是一个MySQL中带有用户ID的巨大表。文件列表将存储与文件相关的其他元数据,因此不能仅使用文件系统。

我的想法是,当用户登录并查看他们的文件时,只显示单个 SQLite 数据库中的所有数据会更快,而不是让 MySQL 遍历“文件”表中的所有记录以提取一个用户的按 ID 归档。每个用户将轻松拥有 10,000 多个条目,并且最初将有至少 400 个用户。那么有 400 个单独的 SQLite 数据库,有 10,000 行,还是一个 MySQL 表有 400 万行?请记住,所有 400 个用户很少(如果有的话)同时登录,让数据库必须为不存在的用户处理数据似乎效率低下,即使它已被索引。

SQLite 的最大限制是锁定,但幸运的是,在这种情况下,只有一个进程写入数据库,所以这里不应该成为问题。备份单个 SQLite 数据库的额外管理是微不足道的,因为无论如何它们都将成为增量文件系统备份的一部分。

想法?意见?我是不是想多了?

【问题讨论】:

  • 如何确保只有一个进程写入数据库?如果用户打开了两个标签怎么办?
  • miki,SQLite 可以处理。
  • Hi Miki -- 用户无法通过界面添加或编辑文件。文件从外部来源“推送”给用户,所有这些都在一个单一的夜间过程中完成。
  • 如果数据库大小成为问题,您可以随时对 mysql 表进行分区。但是 400 多个单独的 sqlite 表意味着必须打开/关闭 400 多个单独的数据库,而使用单个 mysql 数据库,就有机会缓存​​东西。

标签: php mysql sqlite


【解决方案1】:

我的想法是,当用户登录并查看他们的文件时,只显示单个 SQLite 数据库中的所有数据会更快,而不是让 MySQL 遍历“文件”表中的所有记录以提取一个用户的按 ID 归档。

不,如果您正确索引 MySQL 数据库,则不会。如果设置正确,400 万条记录应该不会有任何问题。

【讨论】:

  • 我确信 MySQL 可以很好地处理 400 万条记录,我只是想知道与 SQLite 选项相比,它需要多少服务器资源。没有简单的方法来衡量它。我已经创建了一个 MySQL 数据库,其中包含 10,000,000 条模拟记录,但创建了适当数量的 SQLite 数据库,这要困难得多(我不确定是否值得努力)。
  • 要考虑的一件事是,将其分片到数百、数千或更多 SQLite 数据库将是维护方面的巨大痛苦。如果您需要进行架构更改怎么办?如果您想获取所有用户文件数量的统计信息怎么办?
【解决方案2】:

我一直在使用自己构建的应用程序来做这件事。每个用户都有自己的 SQLite 数据库。我这样做的原因是因为我允许用户将他们的数据备份到 Dropbox,以及将其同步到 iOS 应用程序中匹配的 SQLite 数据库(通过 Dropbox)。

优点:
- 用户数据是隔离的,支持和查看单个数据库很容易。
- 数据随时可以推送到 Dropbox。它易于携带。

缺点:
- 如前所述,模式更改是一种痛苦。我必须在每个 SQLite 数据库中保留一个名为“版本”的表,并跟踪一个版本号,该版本号代表他们的架构是什么样的。架构更改涉及编写复杂的更改查询并遍历存储在我的服务器上的所有数据库文件。
- 打开这么多独立的数据库,服务器可能会承受更重的负载。我怀疑索引 MySQL 数据库会更快。

总的来说,它可以工作,但由于架构更改问题,我实际上希望将所有数据整合到一个 MySQL 数据库中。

祝你好运。

【讨论】:

    【解决方案3】:

    我认为打开和关闭数以千计的数据库文件 (SQLite) 与查询已打开最近的数据库和表的单个服务器实例 (MySQL) 相比要昂贵得多。

    400 个用户也不是。在这些级别上,您可能根本看不到任何性能问题。

    【讨论】:

    • 谢谢埃米尔,我很感激。这是我最初的想法,但获得其他意见总是值得的!
    【解决方案4】:

    我想这根本不会很好地扩展。假设您超出了当前服务器的容量并尝试启动第二个数据库服务器。哪一个有哪些用户 ID? MySQL 的主/从复制意味着您不必担心这个问题。

    我还认为,您运行它的操作系统将很难以优化的方式保存所有这些文件。使用 MySQL,您可以轻松优化表,处理碎片等问题。如果你使用 SQLite,你可能会花费更多的资源来寻找和加载文件内存,而不是 MySQL 寻找表的那个部分。

    这是一个有趣的思想实验,但我认为它不会达到你想要的效果。如果您真的想使某些东西可扩展且快速,请尝试查看 MongoDB:http://www.mongodb.org/。它快速、灵活且可扩展。另外,您可以保留文件列表并搜索上传文件的用户 - 如果您想做类似 Dropbox 的“仅存储我们以前从未见过的文件”,这可能会很有用。

    【讨论】:

      猜你喜欢
      • 2010-09-12
      • 1970-01-01
      • 1970-01-01
      • 2011-09-05
      • 1970-01-01
      • 1970-01-01
      • 2011-03-31
      • 2012-07-23
      • 2014-01-13
      相关资源
      最近更新 更多