针对 EAV 系统的 dbms 的建议，主要需要在 .net 堆栈上进行插入和选择操作
在我一直从事的项目中，数据建模需求是：
一个由 N 个客户端组成的系统，每个客户端都有 N 个事件。事件是一个实体，具有所需的名称和发生时的时间戳。可选地，事件可以具有N个属性（键/值对），定义客户端想要与该事件的特定实例一起存储的属性。
系统主要有：
- 插入 – 事件被记录但从未更新。
- 选择 – 将根据任何可能组合的事件和属性生成/执行报告/操作。
这些需求反映了实体属性值 (EAV) 数据模型。经过一段时间的研究，我觉得像Sql Server这样的关系型数据库管理系统可能不太适合这个。 （如果我错了，请纠正我！）
所以我倾向于 NoSql 选项，如 MongoDb/CouchDb/RavenDb 等。 我的问题是：
- 考虑到我的系统大量的插入/选择需求，可用的 NoSql 解决方案中最适合的是什么？
- 如果这些需求可以转化为关系模式，我也愿意接受关系选项。虽然我个人对此表示怀疑，但在阅读了性能 DBA 的答案（例如 此处引用的），我很好奇。然而，我无法为自己的需求找出最佳的关系模型，也许该系统相当通用。
谢谢！
In the project I have been working on, the data modeling requirements are:
A system consisting of N number of clients with each having N number of events. An event is an entity with a required name and timestamp at which it occurs. Optionally, an event may have N number of properties (key/value pares) defining attributes that a client want to store with the particular instance of that event.
The system will have mostly:
- inserts – events are logged but never updated.
- selects – reports/actions will be generated/executed based on events and properties of any possible combinations.
The requirements reflect an entity-attribute-value (EAV) data model. After researching for sometimes, I feel that a relational dbms like Sql Server might not be a good fit for this. (correct me if I'm wrong!)
So I'm leaning toward NoSql option like MongoDb/CouchDb/RavenDb etc.
My questions are:
- What is the best fit in available NoSql solutions keeping in view of my system's heavy insert/select needs?
- I'm also open for relational option if these requirements can be translated into relational schema. Although I personally doubt this, but after reading performance DBA answers (like referenced here), I got curious. However, I couldn't figure out myself an optimal relational model for my requirements, perhaps the system being rather generic.
thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当您向其中写入非结构化数据（例如您的活动）时，MongoDB 确实会大放异彩。此外，它还能够承受相当重的写入负载。然而，它不太适合报告。至少对于传统意义上的报道来说是这样。
因此，如果您的报告需求很简单，您可能会完成一些简单的映射缩减作业。否则，您可以将数据导出到关系数据库（例如，每晚作业）并报告结果。
这种混合解决方案非常常见（根据我的经验）。
MongoDB really shines when you write unstructured data to it (like your event). Also, it is able to sustain pretty heavy write load. However, it's not very good for reporting. At least, for reporting in the traditional sense.
So, if your reporting needs are simple, you might get away with some simple map-reduce jobs. Otherwise you can export data to a relational database (nightly job, for example) and report the hell out of it.
Such hybrid solution is pretty common (in my experience).