Обычная JSON против встроенной базы данных для React-native?

Question

У меня есть 50-100 МБ данных, к которым у пользователей должен быть доступ. Это stati c, поэтому не имеет смысла размещать для него сервер. Существует два вида операций над данными:

1. Чтение объектов по уникальному ObjectId. Каждый объект составляет ~ 3 КБ.
2. Полнотекстовый поиск по ~ 300 000 строк. Каждая строка состоит из 4-60 символов.

Я собираюсь сохранить данные в виде JSON файлов. 300k строк будут храниться отдельно. Я буду использовать https://github.com/nextapps-de/flexsearch или что-то подобное для выполнения поиска по нему. Я делал нечто подобное раньше с набором данных ~ 10 МБ еще в 2016 году. Я использовал просто поиск по регулярному выражению, и он работал безупречно.

Есть ли причины использовать RealmDB, SQLite, PouchDB или что-то еще вместо JSON?

Answer 1

Я буду sh Я задавал этот вопрос год go ...

В офисе, где я сейчас работаю, мы пытались создать приложение с помощью PouchDB и реагировать на нативные, в основном мы видели PouchDB как преимущество, потому что это не потребовало бы, чтобы наш API отправлял все данные снова и снова на каждом refre sh, инициированном пользователем, он будет отправлять только те данные, которые изменились на основе контрольной точки клиента. Поскольку данные на сервере были довольно тяжелыми (около 6 тыс. Записей с более чем 200 атрибутами в каждой), мы любой ценой попытались go легко справиться с тарифным планом клиента.

Месяцы после внедрения этой реализации мы реализована функция поиска с множеством различных вариантов сортировки и фильтрации, и нам пришлось не только отказаться от всей нашей реализации PouchDB, но и начать с нуля, заменив все ее логики c индексированными значениями JSON. Производительность PouchDB была чрезвычайно медленной, для получения результатов требовалось более 5 секунд, и мы просто не могли позволить себе отложить это время в нашем объеме.

В итоге мы достигли очень быстрого поиск выполняется flex search внутри наших проиндексированных JSON. Не делайте ту же ошибку, что и мы, PouchDB стоил нам слишком много бюджета и драгоценного времени. Это был ужасный выбор.

К сожалению, я не могу предоставить доказательства или более подробную информацию из авторитетного источника, я могу только поделиться своим личным ужасным опытом, который у меня был, когда я думал, что мы подошли к концу проекта, и у нас было начать с нуля. это был беспорядок.

Answer 2

О, мальчик, навязчивый, основанный на мнении вопрос!

У меня около 5 лет опыта работы с pouchDB, немного с SQLite. У меня есть лишь поверхностный опыт работы с RealmDB - я опробовал его и решил, что он не подходит для моих гибридных / мобильных нужд.

pouchDB превосходит по одной области - синхронизация / репликация, как будто она большая брат CouchDB. Обеспечение взаимодействия с автономной базой данных, которая синхронизируется с удаленной базой данных, является огромным для многих мобильных приложений. pouchDB - это схема без использования JSON документов. С pouchDB вы можете выбирать между несколькими хранилищами данных через адаптеры. Поскольку для вашего размера данных могут быть проблемы с квотой ¹ , правильным выбором, вероятно, будет адаптер SQLite. pouchDB не поддерживает полнотекстовый поиск.

SQLite - это то, что подразумевается под его именем - реляционная база данных, требующая схемы. Преимущество SQLite заключается в поддержке платформы, а размер базы данных не подвержен влиянию квот, таких как веб-хранилище (например, IndexedDB). SQLite поддерживает полнотекстовый поиск, и приложения могут развертываться с использованием постоянной базы данных.

Между pouchDB и SQLite лежит RealmDB - это объектная база данных на основе схемы, которая поддерживает синхронизацию / репликацию. Как и pouchDB, он не поддерживает полнотекстовый поиск.

Теперь ваши требования

• Поиск объекта по id
• 300k stati c text
• полнотекстовый поиск

Я читаю 'stati c', что означает неизменный.

Поскольку ваши данные не изменяются, и полнотекстовый поиск требуется, pouchDB и RealmDB не будет хорошим выбором. Если существует необходимость в улучшении, удалении или добавлении данных, то это будет иметь смысл, поскольку изменения данных на одном сервере будут реплицировать изменения в локальной базе данных, практически беспрепятственно.

SQLite может быть разумный выбор, поскольку он поддерживает поиск, и с помощью приложения можно развернуть постоянную базу данных. Тем не менее, SQLite может работать медленно в гибридных приложениях.

Итак,

• pouchDB и RealmDB будут массовым перебором и не подходят.
• SQLite прибавит немало сложности .

Для ваших конкретных c требований я бы остался на вашем пути, хотя у меня есть забота Похоже, что flexsearch загружает свой индекс в память - если его производительность возвращает некоторое наказание, то SQLite с возможностью развертывания постоянной базы данных и предоставлением средства поиска может оказаться разумным компромиссом по сравнению со сложностью.

Удачи!

¹ Головная боль по квоте

Answer 3

Я бы сказал, что на самом деле все зависит от того, хотите ли вы и НУЖНЫ ли вы использовать возможности реляционных запросов. Поскольку ваши данные никогда не меняются, я бы использовал JSON, если вы не пытаетесь выполнить сложные сравнения между вашими данными. В вашем случае кажется, что вы просто будете искать конкретный ObjectId, так что JSON - ваш лучший выбор, особенно потому, что вы говорите, что вам не нужно будет изменять данные позже.

Если вы упорядочите свой JSON так, чтобы ваш ObjectId был в отсортированном порядке, вы легко сможете быстро искать.