原生JSON与应用程式内资料库是否为React-native？

Question

我有50-100mb的数据集，用户需要访问。它是静态的，因此为它托管服务器没有任何意义。我将对数据执行两种操作：

1. 通过唯一的ObjectId读取对象。每个对象约为3kb。
2. 通过约300.000个字符串进行全文搜索。每个字符串是4-60个字符。

我正在考虑将数据存储为JSON文件。 30万个字符串将单独存储。我将使用https://github.com/nextapps-de/flexsearch或类似的东西来对其进行搜索。早在2016年，我就用〜10mb的数据集做了类似的事情。我只使用了正则表达式搜索，并且它运行良好。

是否有使用RealmDB，SQLite，PouchDB或其他替代JSON的理由？

Answer 1

哦，男孩，有丰富的见解的问题！

我对pouchDB有大约5年的经验，对SQLite则有一点经验。我对RealmDB的经验很少，但我尝试了一下，认为它不适合我的混合动力/移动需求。

pouchDB超越了一个领域-同步/复制就像它的老大CouchDB一样。对于许多移动应用程序而言，提供与与远程数据库同步的脱机数据库的交互非常重要。 pouchDB是无模式的，利用JSON文档。使用pouchDB时，可以通过适配器在多个数据存储中进行选择。由于您的数据大小可能会出现 quota头痛 ¹ ，因此正确的选择可能是SQLite适配器。 pouchDB不支持全文搜索。

SQLite的名字含义是-一个需要模式的关系数据库。 SQLite的优势在于平台支持，并且数据库的大小不受网络存储（例如IndexedDB）之类的配额困扰。 SQLite支持全文搜索，并且应用程序可以与罐装数据库一起部署。

pouchDB和SQLite之间存在RealmDB-它是基于架构的对象数据库，支持同步/复制。像pouchDB一样，它不支持全文搜索。

现在您的要求

• 按ID查找对象
• 30万个静态文本
• 全文搜索

我读“静态”表示不可变。

由于您的数据不会更改，并且需要全文搜索，因此pouchDB和RealmDB将不是很好的选择。如果需要增强，删除或添加数据，则两者中的任何一个都有意义，因为对单个服务器上的数据所做的更改实际上可以无缝地将更改复制到本地数据库。

SQLite可能是一个合理的选择，因为它支持搜索，并且可以使用该应用程序部署罐装数据库。但是，SQLite在混合应用程序中可能会变慢。

所以

• pouchDB和RealmDB可能大量杀伤力，并不适合。
• SQLite会增加一些 complexity 。

对于您的特定要求，我会照常行事，尽管我很小心，因为flexsearch似乎会将其索引加载到内存中-如果其性能返回一些损失，则SQLite可以部署罐装数据库并提供搜索工具可能会证明在权衡复杂性方面是合理的。

祝你好运！

---

¹ Quota Headaches

Answer 2

我要说的是，这实际上仅取决于您是否想要和需要利用关系查询的功能。因为您的数据永不更改，所以除非您尝试在数据之间执行复杂的比较，否则我将使用JSON。在您的情况下，听起来您将要搜索特定的ObjectId，所以JSON是您的最佳选择，尤其是因为您说以后不需要更改数据。

如果您组织JSON以使ObjectId处于排序顺序，则可以轻松快速地进行搜索。

Answer 3

我希望我一年前有这个问题...

在我目前工作的办公室中，我们尝试使用PouchDB创建一个应用程序并响应本机，我们基本上将PouchDB视为一种优势，因为它不需要我们的API在每次刷新触发的每次刷新中一次又一次地发送所有数据。用户，它将仅发送基于客户端检查点更改的数据。由于服务器中的数据非常繁重（大约有6k个条目，每个条目具有200多个属性），因此我们不惜一切代价尝试简化客户端的数据计划。

实施此方法后的几个月，我们实现了搜索功能，并提供了许多不同的排序和过滤选项，不仅我们不得不放弃所有的PouchDB实现，而且还必须从头开始，用所有的逻辑替换为索引的JSON值。 PouchDB的性能非常慢，检索结果花费了大约5秒钟左右的时间，而我们不能在我们的示波器上延迟此时间。

最后，我们成功实现了在已索引JSON中运行flex search的快速搜索。不要做与我们相同的错误，PouchDB花费了我们太多的预算和宝贵的时间。这是一个糟糕的选择。

不幸的是，我无法从信誉良好的来源提供证据或更多细节，我只能分享自己以为自己即将结束项目并不得不从头开始时的个人经历。真是一团糟。