处理多个组织/客户

Question

我们正在设计一个应用程序，它将处理各种设备的使用情况数据。这些设备将属于不同的客户端。这些设备的数据将由一个小型使用检测设备收集，该设备将连接到这些设备。我们计划编写一个使用node.js和express的API，它将为我们所有的客户提供服务。该API将由门户，iPhone应用程序和小型使用检测设备使用。

有两组数据 -

1. 数据是为所有客户端常见。这将包括各种设备的校准数据。
2. 每个客户端都独有的数据。这包括收集有关特定设备本身的数据。这将是很多数据，每天在表格中有超过5000条记录。

我们的计划是为每个客户拥有不同的URL。所以Company A将有companya.api.myapp.com和Company B将有companyb.api.myapp.com。但他们将在内部都指向相同的API。我们不会有API（node.js代码）部署在多个站点上。诸如harvest之类的服务具有这样的实现。

对于数据库，我们有两个选择 -

1. 俱乐部所有的数据为所有客户到一个单一的数据库，让每一个表有一个client_id列确定哪些客户端的数据属于。这个数据库将变得非常快速。
2. 拥有所有客户端通用的数据的主数据库，但对于不同的客户端具有不同的数据库。我们将有一个算法，它采用公司名称并确定要连接的数据库的名称，或者我们可以将db_name它存储在客户端表中。这可能是一个维护头痛。

我希望有人能够像这样分享他们的经验，或者评论什么是处理这个问题的最好方法，所以我们可以从正确的方向开始。

编辑：我们计划首先将从特定设备收集的运行时数据转储到哑数据库中。然后数据整理者将定期在该数据库上运行，并将数据推送到多个表中。

Answer 1

我已经实现了数据结构在此之前：

http://sun.systemnews.com/articles/73/2/server/12363

您的这个解决方案的数据结构的假设似乎集中在经典的硬件（通常是基于SQL），如SQL-Server中，甲骨文实现， Postgres，...）带有扇出以支持读取负载。

这将不会扩展（正如您所指出的那样），所以真正的答案不是您提供的解决方案之间的选择，而是尝试与您的使用案例相匹配的新内容。

如果你问我如何在2014年实现这个，我会立刻建议你考虑一个像Cassandra这样的非SQL数据库来进行初始数据捕获。这将允许你配置多个节点（10 s, 100 s，1000 s ...) to scale the data capture high enough to support 100 s）数以千计的设备（又名下一个杀手级iPhone应用程序）Apple使用了大量的Cassandra产品，Blackberry也是如此，Netflicks运行它的业务， Facebook开发它并将其提供给Apache基金会（价格优惠点）;它是按比例构建的，请看一看。您正在询问有关[在高度可用的环境中快速吞吐大量数据的情况，支持通过电话应用程序或网页进行报告的互联网规模以及通过添加新节点来匹配工作负载的能力，这是Cassandra甜蜜点）。它可以在云中，桌面上或桌面下或数据中心或其组合中实施。这就是说，Cassandra对临时报告并不公平，即没有经典意义上的罐装报告，总结报告或分析。如果您希望支持这种类型的工作负载，那么我还会创建一个决策支持系统（真正的数据集市）来汇总Cassandra中的信息并将汇总信息存储在您选择的SQL数据库中。总结会将音量减小到关系模型更易于管理的程度，并利用SQL的功能来为分析负载提供服务。开始看起来像传统的OLTP - >数据仓库两步我们都已经熟悉，只是一个不同的前端。

这足以激起你的胃口。其他一些想法：

1）如何将数据传送到后端非常重要。如何将信息传递回现场可能需要比您想象的更多的工作。看一下像Kafka这样的排队系统，它可以让你在数据中心内用持久性管理尖锐的负载。

1a）允许您的销售模式也包括销售后端。国防部/ Google/Facebook/Apple或其他一些类似的大客户希望能够拥有自己的数据[不知道为什么... :)]。 2）特别关注数据，加密和攻击，iPhone用户不喜欢他们的照片显示他们不应该在哪里;我认为他们对数据有同样的感受。没有更快的方法来闻到不好的气味，而不是成为泄漏的源头（问朱利安）。更好的是，不要拿个人数据。经验法则就像'生命的圈子'一样，只是拿你需要的东西。

3）客户更改，内容更改，设备更改，每个都有新版本，定期：设计数据在网络上尽可能避免装载器地狱。不要让您的中继系统依赖任何收集的数据组件。不要使用XML（胖数据无法运行）。

我希望这给你一些解决方案的备选想法。让我知道你如何继续。