每个客户的SQLite3数据库

时间:2015-10-11 16:28:00

标签: mysql database sqlite rest database-design

情境:

使用symfony2和AngularJS中的前端构建包含RESTful后端的商业应用

  • 许多客户永远不会使用这个应用程序(如果我卖掉100个会很棒的。希望更多,但无论如何都会很大)

  • 我想为数据库建立一个多租户结构,每个客户有一个模式(他们为客户存储敏感信息)

  • 我在更新架构时意识到了问题,但我必须忍受它。

  • 今天我有一个MySQL演示数据库,每次新客户购买应用程序时我都会克隆它。

  • 我的客户之间没有任何关系,因此我不需要与多个分片进行任何查询沟通

  • 对于一个客户,他们当时可以使用来自多个设备的应用程序,但在数据库中不会有大量的写入操作

我的问题

尝试为后端API设置一些功能测试我读到了有关用于加载测试数据的专用sqlite数据库,这似乎是个好主意。

但是我想知道从MySQL切换到SQLite3数据库作为我对应用程序的主数据库支持是否也是一个好主意,如果通常的做法是拥有一个专用的SQLite3数据库PER CLIENT。我从未使用SQLite,我不知道更新模式和复制所有数据库中的更改的过程是否与其他RDBMS相同

这是SQLite的正确方案吗? 关于如何实现这一点的任何建议(也就是教程)?

1 个答案:

答案 0 :(得分:0)

  

[我想知道]拥有一个专用的SQLite3数据库PER CLIENT是否是一种常见做法

仅当数据库与应用程序一起部署时,例如在手机上。否则,我从来没有听说过这样的事情。

  

我从未使用过SQLite,我不知道更新架构和复制所有数据库中的更改的过程是否与其他RDBMS相同

SQLite是一个SQL数据库,它响应ALTER TABLE等。至于更新所有模式,您必须重新运行所有模式的更新。

模式同步通常由外部实用程序处理,通常您的ORM会有一些东西。有些是服务器不可知的,有些只支持特定的服务器。还有专门的数据库变更管理工具,例如Sqitch

  

但是我想知道从MySQL切换到SQLite3数据库作为我对应用程序的主数据库支持是否也是一个好主意,并且

SQLite的主要优势是不要求您安装和运行服务器。这对于快速项目或必须部署数据库的地方很有意义,例如电话应用程序。对于基于服务器的应用程序,使用数据库服务器没有问题。 SQLite非常有限的一组SQL功能成为一个缺点。除了最简单的查询之外,它还可能比服务器数据库运行速度慢。

  

尝试为后端API设置一些功能测试我读到了有关用于加载测试数据的专用sqlite数据库,这似乎是个好主意。

在任何情况下都不应使用与生产数据库不同的数据库进行测试。数据库并不是全部实现SQL相同,MySQL对此特别不好,而且您的测试不能反映现实。运行MySQL实例进行测试并不多。

separate schema thing声称有三个好处......

  • 可扩展性(您可以随时添加字段)
  • 安全性(查询不会意外显示错误租户的数据)
  • 并行缩放(您可以将每个架构拆分到不同的服务器上)

他们提出的建议相当于为每个租户提供单独的,自定义的代码副本。你不会那样做,这显然是一场维护噩梦。代码至少具有版本控制系统的优势,具有分支和合并。我只知道一个支持分支的数据库管理工具Sqitch

让我们想象您已经对租户5的架构进行了自定义更改。现在您有一个通用的架构更改,您想要应用于所有这些。如果5的变化与此冲突怎么办?如果对5的更改要求特殊数据迁移与其他人不同,该怎么办?现在让我们想象您已经对十个模式进行了自定义更改。一百。一千?梦魇。

不同的模式需要不同的查询。应用程序必须知道每个租户正在使用哪个架构,必须有某种您需要维护的架构版本映射。每个不同的可能模式的每个不同的可能查询都必须在应用程序代码中维护。梦魇。

是的,将每个租户放在一个单独的架构中更安全,但这只能防止编写错误的查询或包括查询构建器(无论如何这都是个坏主意)。有更好的方法可以缓解问题,例如文档中建议的view filter。攻击者可以通过许多其他方式访问租户数据,但这并未解决:获取数据库连接,获取对文件系统的访问权限,嗅探网络流量。我不认为小的安全收益值得维护噩梦。

至于缩放,这篇文章已经过时了十年。有很多很好的方法可以实现并行扩展,然后将模式粗略地放在不同的服务器上。有完整的数据库致力于这个想法。幸运的是,你不需要这些!在您拥有数万到数百万租户之前,扩展对您来说不会成为问题。对于一个假设的大型平行缩放问题,前面加载你的设计与模式维护噩梦的想法是把车推到马前,它已经在酒吧里有一品脱。

如果你想使用关系数据库,我会推荐PostgreSQL。它有一个非常丰富的SQL实现,它的速度快,扩展性好,而且它有一些东西可以让整个单独模式的想法变得毫无意义:built in JSON type。这可用于实现"可扩展性"在文章中提到。每个表都可以使用meta类型的JSON列,您可以将任何额外的数据添加到您的列表中。该应用程序不需要特殊查询,meta列始终存在。 PostgreSQL的JSON运算符使得使用元数据非常容易和有效。

您还可以查看NoSQL database。有很多可供选择,许多支持自定义模式和并行缩放。但是,您可能需要更改框架选择以使用支持NoSQL的框架。