Хранилище ключей-значений для средних и больших значений

Question

У нас есть система, которая хранит (однозначные) миллионы изображений размером от 8 КБ до 500 КБ, медиана около 15 КБ, в среднем 30 КБ.Общий набор данных в настоящее время составляет около 100 ГБ.Мы хотим получить доступ к изображению на основе хеша изображения (это может быть изменено , но оно должно быть вычисляемым по изображению с целью проверки, эффективно ли изображение уже находится в хранилище данных -изображения обрабатываются так, что два изображения идентичны по пикселям, если они идентичны по байтам).Постоянство (очевидно) важно.

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

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

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

Answer 1

Резюме: Для ваших требований к целостности данных, постоянству, размеру и скорости я рекомендую Redis .

Хорошую презентацию можно увидеть здесь:
https://simonwillison.net/static/2010/redis-tutorial/

nb Дополнительная информация поможет, но, исходя из того, что вы дали + то, что я знаю, вот некоторые из основных игроков:

Memcached:
https://memcached.org/
Бесплатная, высокопроизводительная система кеширования объектов с открытым исходным кодом и распределенной памятью, подходящая для ускорения динамических веб-приложений.
+ хорошо для веб-приложений, бесплатно, с открытым исходным кодом.
- , если сервер выходит из строя (сбой процесса memcached или перезагрузка системы), все сеансы теряются.Ограничения производительности на более высоких уровнях (для коммерческого использования).

Redis:
https://redis.io/
Аналогично memcached, но с сохранением данных, поддерживает несколько типов значений, счетчики с атомарнымувеличение / уменьшение и срок действия встроенного ключа.
+ сохраняет данные на диск, поэтому никогда не теряется, очень просто, скорость, гибкость (ключи могут содержать строки, хэши, списки, наборы и отсортированные наборы),шардинг, поддерживается vmware, а не отдельным пользователем.
- ограниченная кластеризация.

LevelDB:
https://google -opensource.blogspot.com / 2011/07 / leveldb-fast-persistent-key-value-store.html
Быстрый механизм хранения значений ключей, написанный в Google, который отображает строковые ключи в строковые значения.
+ Google.
- ? Возможно с Google +;)

TokoyoCabinet:
https://fallabs.com/tokyocabinet/
Включает поддержку блокировки, ACID транзакции, тип данных двоичного массива.
+ Скорость и эффективность.
- Меньше известнов некоторых областях, например, US

Project Voldemort:
https://project -voldemort.com /
Расширенное хранилище значений ключей, написанное наДжава.Предоставляет многоверсионное управление параллелизмом (MVCC) для обновлений.Обновление реплик выполняется асинхронно, поэтому оно не гарантирует согласованность данных.
+ Функциональность
- Согласованность

MongoDB:
https://www.mongodb.org/
Масштабируемая, высокопроизводительная база данных с открытым исходным кодом, ориентированная на документы.Написано на языке C ++. Репликация и высокая доступность с зеркалами в локальных и глобальных сетях и автоматическим разделением.Популярный в сообществе Ruby on Rails.
+ Простая установка, хорошая документация, поддержка.
- Относительно новый.

Диван:
http://www.couchdb.org/
Аналогичен Mongo, предназначен для баз данных документов.
+ репликация, расширенные запросы.
- кластеризация, управление дисковым пространством.

Cassandra:
https://cassandra.apache.org/
Apache Cassandra отказоустойчив и децентрализован и используется, в частности, в Netflix, Twitter и Reddit.
+ Кластер и репликация.
- Требуются дополнительные знания по настройке.

Я не могу предоставить все ссылки из-за нехватки времени, но надеюсь, что это хотя бы поможет.

Answer 2

В зависимости от

• количество файлов
• как вы их структурируете на FS
• какую ФС вы используете
• какой тип хранилища вы используете

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

Вы также должны быть осторожны при атомном доступе к файлам (и / или при создании каталогов), в то время как хранилище KV обычно позаботится об этом за вас.

У меня были проблемы со всеми этими вещами в прошлом с подходами fs-as-key-value-store :).

Но это можно сделать, см., Например, Bigdis , который является реализацией протокола redis KV в виде файлов на диске, от самого автора redis, но вы должны быть немного осторожны с ваши операции

В зависимости от вашей проблемы, вы можете найти MogileFS или облачную версию S3 как лучшее решение.

Answer 3

Вы предоставляете слишком мало информации, чтобы дать конкретный ответ - таким образом, только некоторые аспекты, относящиеся к тому, что вы описываете:

• целостность данныхЭто может быть что угодно - то есть несанкционированное изменение данных должно быть запрещено, и / или, по крайней мере, любой такой инцидент должен быть обнаружен ... ИЛИ это может быть просто что-то в области "RAID и / или резервного копирования ...".

• «идентичные изображения»файлы изображений содержат несколько полей / областей метаданных ... ваш метод приводит к тому, что два попиксельных изображения выглядят как разные, если у одного есть метаданные, а у другого нет (или поле метаданных отличается) ... это то, что вам нужно?Другим аспектом в этой области является формат файла (PNG по сравнению с BMP по сравнению с JPEG и т. Д.) И сжатие ... одно и то же изображение и различные форматы и / или алгоритмы сжатия (даже без потерь, такие как ZIP или LZW, хуже с JPEG и т. Д.)классифицировать одно и то же изображение как другое - это то, что вы хотите?

• "сотни тысяч изображений" и "2 КБ - 10 МБ"это не говорит о многом ... то есть, что медиана по сравнению со средним размером изображения / файла?

• доступРаспределен ли доступ к этим файлам / изображениям (как в CDN)?Или это основано на локальной сети?

Существуют десятки других аспектов, имеющих отношение к тому, что вы описываете ...

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

Возможные решения включают, например, распределенную систему (может быть на основе файловой системы / памяти / БД) и / или хранилище на основе SSD и / или RAID и / или SAN и т. Д.

Интересующий вас пункт «KeyValueStore» может быть уместным, но в большинстве случаев обработка такого количества изображений, с которыми я сталкивался в таком магазине, не добавит ни одной уникальной функции (а в некоторых случаях даже навредит).