Подходит ли хранилище значений ключей для использования, которое требует "получить все"?
Основываясь на результатах моих исследований, я подозреваю, что хранилище значений ключей НЕ является подходящим способом, но я хотел получить более направленный вклад в:
- Определите, является ли хранилище значений ключей жизнеспособным решением для моего использования.
- Смогите сформулировать мои причины предпочтения хранилища документов вместо этого.
Чтобы объяснить мой случай использования
У меня есть приложение, которое состоит из множества "документов". В настоящее время они хранятся в своего рода хранилище CMIS. Однако приложение взаимодействует с этими документами только после того, как они были внесены в эластичный поиск. Это означает, что ВСЕ операции чтения будут попадать в эластичный поиск, а все операции записи будут обновлять как эластичный поиск, так и хранилище.
Запрошенные функции показали, что текущий репозиторий слишком строг и что нет никаких причин для принудительного применения схемы модели на этом уровне. Это, конечно, привело к исследованию вариантов NoSQL.
Для того чтобы заполнить эти "документы" в индексе эластичного поиска, они должны где-то жить, и я должен иметь возможность получить все и разбить их на страницы по мере их загрузки в индекс (на этом шаге также есть некоторая агрегация для заполнения поля, которые построены из существующих полей).
Прямо сейчас, get all фактически выполняется поэтапно, в зависимости от типа документа, но это требование может быть предметом переговоров, и вместо этого может быть достаточно простого get всех всех типов, но он не будет идеальным.
В моем понимании хранилищ значений ключей, хранилище ничего не знает о хранящихся в нем значениях, и на них может ссылаться только ключ. Это заставляет меня задуматься о том, могу ли я даже выполнить get all, если не планирую вести полный список ключей где-либо. Я видел, что некоторые хранилища значений ключей поддерживают использование словарей в качестве ключа (redis). Я не уверен, означает ли это, что я мог бы делать запросы по типу (если бы это была запись в словаре) или мне нужно было бы знать полный словарь, чтобы иметь возможность получить значение?
Поскольку заполнение индекса должно происходить только в случае сбоя эластичного поиска, производительность не является моим главным приоритетом (но это, безусловно, не повредит). Мне кажется, MongoDB почти идеально подходит. Я могу хранить документы и легко запрашивать по типу.
- Учитывая мой сценарий использования, кажется ли, что хранилище документов - хорошее решение?
- Может ли это также быть разумно решено хранилищем значений ключей?
- Есть ли другие преимущества использования одного над другим?
В случае, если это имеет значение, для хранилищ документов я сравнивал CouchDB, Couchbase и MongoDB. Для магазинов с ценными бумагами я искал Redis и BerkeleyDB.
2 ответа
В Redis вы можете получить все ключи и значения, немного поработав и выполнив следующие команды:
- СКАН: чтобы получить все ключи
- ТИП: определить тип ключа (строка, хэш, список и т. Д.)
- MGET / HGETALL / etc: чтобы получить фактические значения, в зависимости от того, к какой структуре относится ключ.
Команда SCAN также удобно реализована для вывода всего в 'redis-cli --scan', а также во многие клиентские библиотеки (например, Python).
Возможно, вам придется написать что-то, чтобы это работало для вашего конкретного сценария, надеюсь, это не должно быть слишком сложно.
NB: есть команда KEYS (которая делает то же самое, что и SCAN), которая не рекомендуется для использования в реальном времени. Хотя ничто не мешает вам создать отдельный независимый экземпляр ведомого устройства, выполнить репликацию с главного устройства, отключиться от главного устройства и затем использовать подчиненное устройство по своему усмотрению без какого-либо влияния на что-либо, обслуживающее живой трафик.
AFAIK, Redis не позволяет использовать словарь в качестве ключа, кроме случаев использования функции сортировки по внешним ключам. В вашем случае использование Redis подразумевает, что вы должны вести список всех документов и / или список по типу документа. Хотя это абсолютно возможно и довольно просто, я не вижу особого интереса к использованию Redis там. Redis сияет, когда вам нужны высокие характеристики. Для вас это не является обязательным требованием, поэтому лучше использовать базу данных документов.