我正在开发一个介于电子邮件服务和社交网络之间的网络应用程序。我觉得它未来有潜力变得非常大，所以我担心可扩展性。
我决定为每个活动用户创建一个单独的 SQLite 数据库：每个“分片”一个活动用户，而不是使用一个集中式 MySQL/InnoDB 数据库，然后在那时对其进行分区。
这样备份数据库就像复制每个用户的数据库一样简单small每天一次将数据库文件发送到远程位置。
扩展就像添加额外的硬盘来存储新文件一样简单。
当应用程序增长到超出单个服务器时，我可以使用 GlusterFS 在文件系统级别将服务器链接在一起并不变地运行应用程序，或者安装一个简单的 SQLite 代理系统，该系统将允许每个服务器操作相邻服务器中的 sqlite 文件。
并发问题将是最小的，因为每个 HTTP 请求一次只会触及一到两个数据库文件（数千个），而且 SQLite 无论如何都只会阻塞读取。
我敢打赌，这种方法将使我的应用程序能够优雅地扩展并支持许多很酷的功能unique特征。难道我赌错了？我错过了什么吗？
UPDATE我决定采用一个不太极端的解决方案，到目前为止效果很好。我使用固定数量的分片 - 准确地说是 256 个 sqlite 数据库。每个用户都通过一个简单的哈希函数分配并绑定到一个随机分片。
我的应用程序的大多数功能只需要每个请求访问一两个分片，但有一个特别需要对 256 个分片中的 10 到 100 个不同分片执行简单查询，具体取决于用户。测试表明，如果所有数据都缓存在 RAM 中，大约需要 0.02 秒或更短的时间。我想我可以忍受！
更新2.0我将该应用程序移植到 MySQL/InnoDB，对于常规请求能够获得大约相同的性能，但对于需要分片遍历的请求，innodb 的速度要快 4-5 倍。由于这个原因和其他原因，我放弃了这个架构，但我希望有人在某个地方找到它的用途......谢谢。
如果您必须执行所谓的“分片遍历”，即找出一堆不同用户的所有数据，则会失败。这种特殊类型的“查询”必须以编程方式完成，依次询问每个 SQLite 数据库 - 并且很可能是站点中最慢的部分。在数据被“分片”到单独的数据库的任何系统中，这是一个常见问题。
如果所有数据对于用户来说都是独立的，那么这应该可以很好地扩展 - 使其成为一种有效设计的关键是了解数据可能将如何使用以及来自一个人的数据是否会进行交互与来自另一个人的数据（在您的上下文中）。
您可能还需要注意文件系统资源 - SQLite 很棒、很棒、速度很快等 - 但是在使用“标准数据库”（即 MySQL、PostgreSQL 等）时，您确实会获得一些缓存和写入的好处，因为它们如何是被设计的。在您提出的设计中，您将错过其中的一些内容。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
