【发布时间】: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 数据库,就有机会缓存东西。