Какое самое быстрое хранилище ключей для хранения без памяти для Node.js, поддерживающих несколько процессов?
Мне нужно хранить простые строки строки/строки для ключей (не документы или JSON, просто строки).
Вот несколько примеров (их было бы миллионы):
Я пробовал:
Обходной путь для LevelDB - multilevel, который предоставляет один процесс LevelDB, хотя HTTP.
Но это, конечно, стоит дорого; Мне нужно что-то быстро.
Есть ли какое-либо хранилище ключей, которое:
Я только забочусь о чтении. Быстрое чтение нескольких процессов необходимо, но не писать.
Я доволен текущей скоростью LevelDB, просто не с тем, что это однопроцесс.
Дополнительная информация:
Я бы предложил посмотреть LMDB (который является наиболее эффективным движком для OpenLDAP и используется в ряде других open- исходные проекты).
LMDB - это встроенное хранилище ключей/значений с API Berkeley-DB или LevelDB, не нужно хранить все в памяти и поддерживать доступ к нескольким процессам. Есть привязки Node.js:
Вы можете попробовать ssdb, базу данных, совместимую с протоколом redis, построенную на leveldb.
https://github.com/ideawu/ssdb
Вы можете использовать существующий клиент node-redis, хотя некоторые из команд могут отличаться.
Redis (100.000x)
13,540 op/s ⨠ set small
13,289 op/s ⨠ set medium
13,279 op/s ⨠ set large
13,651 op/s ⨠ get large
13,681 op/s ⨠ get medium
14,428 op/s ⨠ get small
SSDB (100.000x)
12,252 op/s ⨠ set small
11,824 op/s ⨠ set medium
11,720 op/s ⨠ set large
13,810 op/s ⨠ get large
13,593 op/s ⨠ get medium
12,696 op/s ⨠ get small
lmdb (100.000x)
4,616 op/s ⨠ set small
11,104 op/s ⨠ set medium
17,283 op/s ⨠ set large
13,778 op/s ⨠ get large
16,002 op/s ⨠ get medium
50,562 op/s ⨠ get small
multilevel (100.000x)
6,124 op/s ⨠ set small
5,900 op/s ⨠ set medium
5,944 op/s ⨠ set large
6,215 op/s ⨠ get large
6,125 op/s ⨠ get medium
6,310 op/s ⨠ get small
Как вы можете видеть, ssdb работает почти так же быстро, как redis, и он предназначен для постоянного хранения. lmdb @didier-spezia упоминается очень быстро для получения небольших данных, но установка одного происходит медленно.
Существует FaceBook RocksDB, который должен быть быстрым (особенно в хранилище SSD), а также есть другие, такие как LMDB ( уже упоминалось) и WiredTiger
Вы упомянули Redis. Если вы хотите использовать Redis API, но в качестве хранилища вместо вашей оперативной памяти есть одна из вышеперечисленных баз данных Key/Value, есть два проекта, которые я знаю (хотя они их не тестировали): LedisDB (написано на Go) и ardb (написано на С++).
Недавно я начал тестировать то, что кажется очень многообещающим, хотя и менее известным (хотя я уверен, что это изменится) библиотека значений ключевых значений с именем CuttDB. Он имеет очень высокую производительность и предназначен для обработки больших объемов данных на жестком диске. Он даже включает интерфейс сервера Memcached.
Проблема, с которой вы столкнетесь, заключается в том, что "молниеносно" и диск не смешиваются, особенно если вы читаете произвольный доступ, как и в системе с ключом. Вам нужно получить как можно больше данных в памяти, так как чтение из памяти на несколько величин быстрее, чем чтение с диска.
Является причиной, по которой вы хотите минимизировать память, потому что это будет встроенная база данных? Если это так, вы можете посмотреть на Empress - http://www.empress.com. Использовали его в нескольких проектах, и вы можете настроить, сколько будет загружено. Тем не менее, он получил накладные расходы на РСУБД, поэтому не уверен, что он будет таким худым, как вы хотите.
Вы также можете рассмотреть MySQL с аддоном Memcache. Это позволяет использовать MySQL в качестве хранилища ключевых значений. Гораздо быстрее, чем обычный MySQL, поскольку вы пропускаете обработку уровня SQL. Кроме того, с MySQL вы можете поворачивать ручки для воспроизведения с использованием объема памяти.
Firebird - это еще одно использование низкой памяти db - http://www.firebirdnews.org/docs/fb2min.html.
В любом случае, надеюсь, что это поможет. Без более глубокого объяснения ваших потребностей (встроено ли это, почему необходимо экономить память, и если память драгоценна, что вы считаете низким потреблением памяти, вам нужна кислота, избыточность, что вы считаете молниеносной и т.д.) Ее трудно дать больше анализа.
Почему бы вам не использовать MySQL (или MariaDB) с репликацией Master-slave. Исходя из ваших требований. Архитектура master-slave MySql подходит вам.
В принципе, для NoSQL требуется много серверов. Например, минимальная настройка MongoDB требует три сервера, для HBase требуется четыре сервера.
В этой точке зрения, если вам нужна более читаемость, добавьте новый подчиненный сервер в архитектуру mysql.
Мы предполагаем, что производительность чтения mysql составляет 2 тыс. tps. Тогда четыре node производительности чтения mysql составляют 8k tps.
Это зависит от результата теста и использования службы (соотношение чтения/записи).
проверьте ниже ссылку, то есть "Марко Чеккони - Архитектура StackOverflow". http://www.youtube.com/watch?v=t6kM2EM6so4