减少有用户的dbs

 

任何数据库最重要的特性之一就是查询速度。 我们存储数据并希望快速访问符合我们标准的数据。 但是，最近，无模式数据库已经变得流行起来。 如果我们有一个无模式数据库，但实际上有一个推断（头脑内/应用程序内）架构，这是一回事; 它只是没有被数据库正式声明。

另一方面，比方说，我们确实需要一个开放的数据库，其中几个用户拥有自己的个人问题领域的模式。 用户将定义他自己的“域”。 该域（RDBMS服务器上的数据库）将具有其类型（RDBMS中的表），并且这些类型将具有其自己的特性（RDBMS中的列）。 如何创建复合索引来从给定域中抽取特定对象/文档/记录（你有什么）？ 我的查询应该选择一个或多个域（一个IN子句），只是一个主题类型（例如CalendarEvent），针对某些列（start_date> = today，start_date <= today + 1 week，open_for_registration = true，calendar_name ='Public' ）。 在具有固定模式的数据库中（即使未声明也暗示），这很简单：您可以针对列创建复合索引。

复杂性在于，我们实际上已经创建了一个实例，让我们说MongoDB的行为就像一个拥有许多数据库的RDBMS服务器，其中每个数据库及其相关模式都是我们的“域”。

在解决了这个问题一周并查看各种数据库（MongoDB，Neo4j，MySQL，PostgreSQL）之后，我只找到了一些可能的解决方案：

  • 索引所有属性。 属性可以在属性表中表示，也可以在MongoDB中表示为嵌入式文档。 在RDBMS中，属性值必须被序列化为字符串。 CONS：a）一次只能针对一个属性进行搜索（没有复合索引），b）所有内容都获取索引，因此我们招致不必要的开销。
  • 索引选择属性。 在PostgreSQL中，这可以使用过滤索引来完成。 基本上，财产记录会有一点叫做“索引”，我不得不维护。 这个位会驱动过滤索引是否使用该特定属性。 CONS：a）我们仍然只能一次搜索一个物业。 这消除了使用中的“复合索引”。 我可以想象的模仿复合索引的唯一方法是搜索每个单独的索引属性并返回PK的交集。
  • 创建/维护数据库结构以反映工作索引。 在MongoDB中，我可以创建一个“可索引”集合。 此集合中的文档可能如下所示：{domain_id：ObjectId（..），type_id：ObjectId（..），fields：{field1：“some int value”，field2：“some date value”，field3：“some位值“}}。 然后我索引{domain_id：1，type_id：1，“fields.field1”：1，“fields：field2”：1，“fields：field3”，1}上的“indexables”集合。 然后每次我在我的“东西”集合中创建/更新一个文档时，我都必须将它的值插入到可索引的field1，field2，field3插槽中。 （这很适合MongoDB，因为我可以将任何数据类型的值插入这些占位符中。在MySQL中，使用相同的模式，我必须将值序列化为字符串。）我还必须维护domain_id和type_id。 基本上，它是建立在由数据库处理的索引之上的索引层（我自己管理自己）。 缺点：有额外的开销。 虽然数据库通常会代表我管理索引，但我现在必须自己照顾自己。 由于MongoDB没有交易的概念，我不能保证文档和它的各种索引都是在一个步骤中完成的。 优点：我有复合索引。 索引是在域级维护的。
  • 我曾考虑允许用户拥有自己的数据库X实例，或者在MongoDB中拥有自己的集合。 但是我想知道这是否会造成更多的问题，特别是当我们遇到实际的限制时（允许的数据库或集合的数量）。 我没有太多的想法后抛出了这个想法。

    • 其他想法？ 其他类型的数据库可能更好地处理这个问题？

    同样，这个想法是这样的：不同的用户管理自己的域名。 在一个域中可以是任何“类型”的项目。 对于每个类型的项目我们有属性。 我希望允许用户针对他们的域运行查询以获取具有与其条件匹配的属性的项目。 （因此复合指数）

    最后一个想法。 一个领域本身并不打算成为一个巨大的领域。 它可能有10-20个“类型”。 在每种类型中，它们可能多达5000条记录（在大多数情况下），在极端情况下可以说为20000条记录。

    不幸的是，尽管Joel Spolsky的建议是我尝试宇航员的建筑，但这仍是其中一例。

    其他类型的数据库可能更好地处理这个问题？

    你有没有考虑过Excel？ 也许只是索引平面文件:)

    看，你将会遇到的基本问题是没有银弹。 你的想法很好，但在某些时候你必须接受一些权衡。

    你不能索引一切。 在某些时候，您必须确定“常用”查询并为这些事情建立一些索引。 除非你计划将所有内容都保存在内存中，否则最终会在某个时候创建​​索引。

    在每种类型中，它们可能多达5000条记录（在大多数情况下），在极端情况下可以说为20000条记录。

    嘿，这是一个真正的限制。 5k记录可以扔多少硬件？ 200k记录怎么样？ 是否足以将它全部保存在RAM中？ 把它的一部分保存在RAM中？ 只保留索引在RAM中？

    如果你想让用户使用自己的“动态”模式，我个人觉得MongoDB是非常合适的。 特别是对于这些小数据集，你正在指出。

    但这绝不是一个银弹。 这些解决方案中的每一个都会有自己的问题。 如果有一个真正的数据库可以处理您提出的所有要求，让我们面对它，我们都会使用该数据库:)

    链接地址: http://www.djcxy.com/p/57907.html

    上一篇: less dbs having user

    下一篇: Mongo Triple Compound Index