具有多列可按范围搜索的大量条目的体系结构

Question

该数据库由一个主表组成，每个表有100万个条目，每个条目大约有100个字段。

大多数字段是数字的，搜索将按范围进行，而不是精确值。searchable

• Easily

• 可以同时搜索多个字段(仅搜索或不搜索OR)，每个条目都有根据其他字段计算的每个列

• 值的数据，还可以搜索

<代码>G 211的列。

哪种架构最合适？

• 使用SQL还是NOSQL更好？可能是弹性搜索吗？
• ，如果SQL，那么数据应该以“传统”方式(大量列)

存储吗？

Answer 1

这样的表结构在SQL中更难优化，并且会在同一个表上涉及许多不同的索引，从而导致大量的存储占用。

轻松添加/删除列

这一要求通常指向NOSQL的方向，但在SQL中，可以通过修改查询或视图来实现这一点，如果您要添加或删除列，则表示数据是从其他现有表引用的，或者有某种形式的CRUD或数据操作接口。在这个实例中，SQL可以归结为您想要执行的数据更新的类型，如果它们是每个文档，或者如果您需要批量更新支持的话。在大多数现实中，在SQL和NOSQL中实现这一目标所需的努力应该是相同的，并且仅限于您对如何在所选体系结构中完成任务的知识。

有大约100个字段。

这表明数据不是以规范化的形式出现的，这意味着我们从SQL获得的许多通过NOSQL的好处没有被利用。

这并不是说SQL对这种类型的数据不好，只是与使用NOSQL或弹性搜索之类的专用搜索API相比，为这样的单个表设置一个完整的SQL数据库并不是一个令人信服的论点。

如果您已经有了一个管理此业务数据的其他数据方面的数据库架构，并且不关心性能或实现最佳性能的成本和努力，那么它可以在SQL中很好地工作。

基于搜索或读取性能的最佳方法是使用专用的搜索索引提供程序。弹性搜索是一个很好的选择，我使用Azure认知搜索这是类似的，数据仍然存储在数据库中，虽然通常以规范化的形式，然后一个投影的数据或视图被上传到搜索索引提供者。应用程序搜索查询是针对索引执行的，根据索引中的结果，如果需要，或者在用户从结果中选择了特定记录之后，应用程序可以从数据库重新查询。

如果使用SQL，那么就没有一个简单的规则来声明是否应该规范数据集。规范化主要帮助管理和更新数据，它还将通过在数据上拥有一组良好的默认索引而有所帮助，这样就可以有效地查询超过100个字段的视图。在不进行正常化的情况下，您需要使用索引对数据库进行调优，以支持搜索参数。