一个大的MySQL数据库还是一千个小的SQLite数据库？

我正在研究基于Web的组织工具.我并不瞄准与美妙的Basecamp相同的市场,但让我们说用户和数据交互的方式看起来一样.

我将不得不处理用户自定义,文件上传和图形调整.每个帐户都有一个论坛.我想提供一种轻松备份每个帐户的方法.

我一直在考虑如何创建一个合理的体系结构,并且已经过训练,可以在一个(如果需要的话,还需要分发)MySQL数据库中使用精美的规范化数据.最近我一直想知道:是否可以考虑使用一个SQLITE DB存储每个帐户的数据,并仅使用MYSQL进行常规网站管理？

亲:

备份很简单:设置版本,zip,上传.

如果每个帐户都使用大量论坛,请不要理会:每个帐户都有一个文件.

SQLITE快速闪电,没有昂贵的连接时间......

表格方案简单得多:每次都不需要对帐户进行任何区分

缺点:

不知道它是否可扩展

不知道硬盘是否会跟上

不知道是否有办法让SQLITE不存储在RAM中,因为它很快就会成为灾难

很多目录和子目录:这样可以吗？

维护问题:升级实时站点意味着逐个升级所有数据库

开发问题:设置dev/pre prod/prod env会很困难

commom数据仍然需要使用mysql,所以我们最终会为每个页面结束2个DB连接,arg

更有利于专业人士,它仍然让我怀疑(zepplin风格).

你说什么 ？

基本上你的问题是:对于多租户SaaS应用程序,上述哪一项更好？

一千个小的sqlite数据库可能会吸引人,但可能无法扩展.

我将依次解决你的观点:

备份很简单:设置版本,zip,上传.

如果在备份期间发生更新,会发生什么？您的备份需要多长时间(例如,每个帐户有一百万个帖子)？您的备份是在备份期间锁定数据库,还是备份数据的一致视图,或者两者都没有？在每种情况下,更新期间进行的数据库备份是否正确恢复？你测试过这些东西吗？

我认为备份一个sqlite数据库并不像你想象的那么容易,因为并发访问问题.

SQLITE快速闪电,没有昂贵的连接时间......

你暗示MySQL连接时间"昂贵"可能是错误的.你有硬数据吗？通过LAN连接到服务器在实践中不需要很长时间.

表格方案简单得多:每次都不需要对帐户进行任何区分

如果您需要更改这1,000个小型数据库的架构,您是否考虑过如何进行迁移？它对服务有什么影响？

我现在要添加一些我自己的:

可伸缩性:如果您依赖于具有锁定语义的本地文件系统(我相信sqlite会这样做),您不能简单地添加更多Web服务器,因为它们将拥有自己的文件系统.

由于sqlite不是基于网络的系统,因此您不能只添加更多Web服务器.您需要在多个服务器上对用户进行分区,并确保它们只能访问自己的"主"服务器(这会引入一些问题,但可能是可行的),或者找出在服务器之间共享sqlite数据库的方法这不会很漂亮,并且可能会消除它曾经拥有的任何感知性能优势(例如)MySQL.

可维护性 - 如果您的开发团队曾对数据库进行架构更改(这不仅是可能的,但非常可能),则需要将其应用于这1,000个小型数据库.成功.有了回滚计划.

我认为用一千个小的sqlite数据库扩展系统将无法扩展.特别是,你最终可能会发现,而不是1000个微小的,最终会有995个微小的,5个相当大的.

使用专用的MySQL服务器将使您能够执行集中备份和迁移.它将使您能够使用该框中的资源(即RAM)来缓存数据库中最常用的部分,无论它们恰好在哪个帐户中.

用于缓存大型MySQL数据库(例如Innodb缓冲池)的RAM可以在请求之间重用,并在其中的所有数据(例如表,行,列)之间共享.每次需要时,sqlite数据库都会从光盘中读取数据,但在单个会话中除外.

我的建议:

考虑以上几点,如果你愿意,可以忽略它们

在生产级硬件上以高模拟负载测量应用程序的性能.确保为数据库服务器使用生产级硬件(例如电池供电的raid控制器)

如果可以的话,将它与sqlite实现进行比较.

我给了它更多的想法,我看到更多的问题:

如果我想为所有论坛使用公共区域,我会被吸烟

如果我想搜索所有的网站,它将是世界末日

如果我想要统计数据,上帝拯救我的灵魂

这是个坏主意.

无论如何,在SO上写它迫使我认真考虑它.在开始之前最好有清醒的头脑.

如果有一天,有人像我一样愚蠢,希望他能打到页面,这样可以帮助他重新考虑

喜欢这个网站(即使它是ASP :-p):最快的方式来帮助自己,同时还要帮助别人.