0

对于我们的一项 SaaS 服务，我们正在调查使用哪个数据库，因为我们正在从头开始重新设计它。

我们当前的解决方案使用 MySQL 并为每个新客户创建一个单独的数据库。当前（全局）结构是：

- globaldb.globaltable
    => some global data shared with all customers
    => big
    => it would be an option to flatten this data in the customerdb.tablewithreportlines, but this increases the size quite a bit

- customerdb.tablewithstaticdata
    => joins with `globaltable`
    => searched on several columns
    => no group by
    => writes throughout the day, in the thousands
    => reads on request by the customer via the application, so not continuesly
    => can be big per customer, serveral GBs

- customerdb.tablewithreports
    => searched on several columns
    => writes throughout the day, but only in the tens
    => reads on request by the customer via the application, so not continuesly
    => quite small

- customerdb.tablewithreportlines
    => joins with `tablewithreports`
    => joins with `globaltable`
    => most columns are 'searchable'
    => most columns are 'groupable'
    => writes throughout the day, in the thousands but only when processing the `tablewithreports` lines
    => reads on request by the customer via the application, so not continuesly
    => can be big per customer, serveral GBs

customerdb数据永远不会被更新，而只会被插入（偶尔会被删除）。

我们正在为快速增长做准备，需要一个为此做好准备的结构。手动添加新实例（如果需要）是可以接受的。

我们之前为一个测试项目设置了一个带有大量表（和数据库）的 MySQL。该项目失败，因为服务器超出了 MySQL 表的最大文件处理程序。这大约是 +-500.000 张桌子。这个新项目肯定需要能够处理 500.000 个客户，因此需要处理 150 万张表（采用当前结构）。

每个客户数据库的平均大小为 +- 7,5Mb。没有太多，但由于一些客户在他们的数据库中有多个 GB，因此它非常普遍。

我搜索了 SO 和 Google 以找到匹配的情况，但无法找到它。

在这一点上，我们对任何建议持开放态度，无论是关系型、NoSQL 还是组合，因为我们正在进行全面的重新设计。

质疑最适合这个用例的数据库是什么？

PS：这是我的第一篇文章，请原谅我的不完整

4

1 回答 1

0

我建议考虑为所有客户使用一个通用数据库。这从根本上减少了表的数量。

数据库管理系统不是为这么大的数据库或表设计的。

通常，表是一个实体，表示同类对象的集合。因此，所有相同类型的对象（例如您的客户）都应该放在一张桌子上，而不是为每个客户准备一张单独的桌子。

于 2016-01-17T09:27:42.943 回答