极端分片:每个用户一个SQLite数据库

我正在开发一个介于电子邮件服务和社交网络之间的Web应用程序.我觉得它有可能在未来发展壮大,所以我担心可扩展性.

我决定为每个活跃用户创建一个单独的SQLite数据库,而不是使用一个集中式MySQL/InnoDB数据库然后对其进行分区:每个"分片"一个活跃用户.

这样,备份数据库就像每天一次将每个用户的小型数据库文件复制到远程位置一样简单.

扩展将像添加额外的硬盘来存储新文件一样简单.

当应用程序超出单个服务器时,我可以使用GlusterFS在文件系统级别将服务器链接在一起并运行应用程序,或者构建一个简单的SQLite代理系统,允许每个服务器操作相邻服务器中的sqlite文件.

并发问题将是最小的,因为每个HTTP请求一次只能触及一个或两个数据库文件,成千上万,而SQLite只会阻止读取.

我敢打赌,这种方法可以让我的应用程序优雅地扩展,并支持许多很酷和独特的功能.我打错了吗？我错过了什么吗？

更新我决定采用一种不太极端的解决方案,到目前为止工作正常.我正在使用固定数量的分片 - 准确地说是256个sqlite数据库.通过简单的散列函数将每个用户分配并绑定到随机分片.

我的应用程序的大多数功能每个请求只需要访问一个或两个分片,但有一个特别需要在256到10个不同的分片上执行简单查询,具体取决于用户.测试表明,如果所有数据都缓存在RAM中,则需要大约0.02秒或更短的时间.我想我可以忍受这个!

UPDATE 2.0我移植应用到MySQL/InnoDB和能够得到有关规则请求相同的性能,但对于需要碎片步行一个请求时,InnoDB快4-5倍.出于这个原因,以及其他原因,我正在放弃这种架构,但我希望某个地方找到它的用途......谢谢.

这将失败的地方是你必须做所谓的"碎片行走" - 这是在一堆不同的用户中找到所有数据.这种特殊的"查询"必须以编程方式完成,依次询问每个SQLite数据库 - 而且很可能是您网站中最慢的方面.在任何将数据"分片"为单独数据库的系统中,这是一个常见问题.

如果所有数据都是自包含给用户的,那么这应该很好地扩展 - 使这个有效设计的关键是知道如何使用数据以及来自一个人的数据是否将进行交互来自另一个人的数据(在您的上下文中).

您可能还需要注意文件系统资源 - SQLite很棒,很棒,很快等等 - 但是当你使用"标准数据库"(即MySQL,PostgreSQL等)时,你会得到一些缓存和写入的好处'设计.在您提出的设计中,您将错过其中的一些设计.

对我来说就像维护噩梦一样.当架构在所有这些DB上发生变化时会发生什么？