Pull to refresh

Comments 50

А какие у него требования к памяти? Может ли работать со своим пространством, не загружая его целиком в память?
По потреблению памяти инфы нет. По поводу работы, не загружая в память, — может. Это on-disk storage.
Пока разбирался с установкой (а у нее есть подводные камни), вышла MariaDB 5.3 release, OLAP средствами которой меня устраивает по скорости и не требует особых плясок с бубном.
Статья мутно-маркетинговая. Кто понял, расскажите, в
чем отличие от известных приемов запихивания атрибутов
в биты ключа, как это делает instagram, например.
Олег, уж с вашей специализацей, опытом и, наверняка, знанием английской технической терминологии -, уверен, не составит труда прочитать всего 15 страниц полного описания + есть ссылка на патент + доступны исходники. И, вместо проявления неуважения к чужому труду, могли бы дать оценку проекту как специалист по базам данных.

Топик — вводный. Авторы заявили о проекте в широкие массы только вчера.
Упаси бог, какое неуважение?! Я высказался о статье, которую мусолил еще неделю назад.
А с массивами оно работать умеет? перерыл сайт их инфы не нашёл.
Странное сравнение HyperDex с Cassandra и MongoDB — они же все три разные.
Кассандра при этом древнейшая
Тоже удивило, учитывая количество оптимизаций по производительности в 1.x версиях очень это подозрительно. Один только read repair убивает в ванильной 0.7.3 производительность по чтению сильно.

И вообще Cassandra оптимизирована на быструю запись, не понятно зачем с ней сравнивать решение оптимизированное на быстрое чтение…
База где хранится, в RAM или на диске?
Каково потребление RAM и процессора в сравнении с конкурентами?
Как происходит работа с процессором, атомарно как в редис(из чего вытекает что 1 инстанс — 1 ядро), или многопоточно?
Mongodb то же грешит одним инстанцом на ядро.
А клиенты увы, пока только под C++, Java, Python…
На сколько я видел у них на сайте пока что только есть для c,c++ и python
На гитхабе у них под java лежит.
Клиент на C легко используется из любого языка с вменяемой поддержкой сишных либ.
правильнее было бы с редисом сравнивать, а не с монгой
Они считают раз NoSQl значит можно всех сравнивать
У них есть на сайте чуть-чуть про redis vs hyperdex:

There's new performance numbers comparing HyperDex to Redis. In every workload, HyperDex is faster than Redis. This is especially true for the SEARCH workload where HyperDex is a full 14 times faster than Redis!


Тем не менее они не включили редис в красивые бенчмарки с картинками :(
что-то скрывают)))))
HyperDex — on-disk storage как и монга, к примеру. Redis — in-memory storage с фичей дампа данных на диск.

С редисом сравнили на операциях досутпа к кэшированным в памяти данным лишь, чтобы показать преимущество в задачах поиска по неиндексным значениям атрибутов объектов (что редис не умеет делать)

С сайта:
Redis offers advanced datastructures, but this comes at a cost: all data must fit in memory, and the system must be deployed in a single-master configuration. HyperDex does not suffer these limitations, and also provides higher performance.
Очень круто! Редис быстрый, но за это заплачено отсутствием поиска по value (можно только по key), а в Resque очень хотелось бы иметь команду find_or_enqueue, чтобы не дублировать таски, но это невозможно сделать с текущим решением (используется структура List Redis-а).

В HyperDex value-поиск есть и я не удивлюсь, если Resque или подобное решение скоро переедет на него.

youporn переедет :) Они тоже на редисе
Я, надеюсь, вы понимаете, что Redis не позиционирует себя как универсальную базу? Используете его для задач, где не нужен поиск по value, и этот «минус» сразу исчезнет.
Конечно) Не универсальный, но быстрый, в этом и идея.

Поэтому я и привел пример, где классно было бы иметь поиск по value — find_or_enqueue для Resque (библиотека для выполнения задач в фоне, написанная на Ruby) который использует Redis в качестве хранилища.
Господи, нет термина субпространство, бывает подпространство.
Пространства господни неисповедимы сын мой! :)
Хорошо, хорошо, не надо больше минусовать. В следующий раз напишу в личку автору.
Чесслово, раньше в статье фигурировало субпространство :-)
Нет информации о протоколе, транзакциях, реакцию на сбой в сети.
Нет версии под Windows.

Клиентские библиотеки только под C, C + + и Python.

Я просто сейчас ищу себе NoSQL базу и эти моменты мне важны, буду смотреть за этой базой но сейчас использовать не буду.
Очень жаль, что вы не сможете использовать эту базу. Но очень хорошо, что вы описали причины вашего решения. Я уверен, разработчики обязательно зайдут на хабрахабр и сделают всё, чтобы исправить описанные вами проблемы и недостатки.
ИМХО любая база данных должна пройти стадию созревания в несколько лет. Молодые базы могут быть очень нестабильны
Плохой подход. Вы своему коду тоже даёте полежать несколько лет перед тем, как отправить его в продакшен?
Потестите у себя — если минусов больше, то не используйте.
Или хотите сказать MySQL и ничего больше сейчас? Если да, то назову несколько задач, с которыми Redis справится на несколько порядков эффективнее, хотя этой базе нет нескольких лет.
Вы все воспринимаете буквально? Оптимальное решение задач это только одна причина. Еще есть:
  • наличие вменяемой документацией
  • консистентность данных
  • наличие 3rd-party тулзов
  • комьюнити саппорт
  • цикл релизов
  • поддержка различных языков


У успешных продуктов это появляется со временем, а плохие просто умирают. Цикл времени может быть разным, но я для себя вывел несколько лет.
По статье непонятно чем это отличается от разряженных многомерных массивов.
Как бы даже не название :)
Я имел в виду старый добрый M/MUMPS: MSM, Cache, GT.M.
Уже перечитал и хабрастатью и часть сайта, а разницу в подходе не понял, чувствую, что чем-то отличается, но конкретно понять не могу.
Странно, что в обсуждении ни разу не упоминается OLAP.
Судя по алгоритму работы, на запросах с полнотекстовым поиском HyperDex подпросядет до уровня остальных БД, если не ниже, следовательно круг использования сужается, до фаст-фуд-сервисов, а-ля тумблер, твиттер.
Вам не кажется, что вы сильно завышаете необходимость полнотекста?
А ещё мне кажется, что ошиблись в примерах. Как раз на том же твиттере и тумблере полнотекст может быть необходим.
Нет, не сильно завышаю. Если бы вы сталкивались с системами документооборота, то не задавали бы таких вопросов.
И опять же для сервисов использующих модель быстро устаревающего контента полнотекстовый поиск заменяется рубрикацией, тегами и тематической группировкой, чаще всего этого более чем достаточно. Тумблер, например, не использует полнотекстовый поиск как таковой.
Я лишь уточнил, что не стоит смотреть на синтетические бенчмарки, приведенные без детального описания правил тестирования. Лучше проанализировать поведение и на основании этого делать выводы в какую нишу метит новичок. А сравнивать теплое с мягким знаете ли…
А я вот знанимаюсь не документооборотом, а аналитикой и статистикой. И анализ текста в 95% случаев мне совершенно не нужен, а вот к распределённым хранилищам у меня есть большой интерес. Так что ваша классификация «круг использования сужается, до фаст-фуд-сервисов» мне кажется неверной.

Неужели вы считаете, что например, астрономы обрабатывающие полученные данные — «фастфуд»?
Если вы обрабатываете однотипные данные, то для этого был создан SQL. А распределенные хранилища не самоцель: вы их хоть на файлах можете организовать.
Предложите мне пожалуйста распределённое SQL хранилище для сбора и анализа различных статистических срезов по пользователям и их активности. В хранилище, допустим, я положу сущность profile и click. Profile — суть таблица Users, click — суть access_log. И вот я хочу найти самое активное время для американцев возрастом 36-48 лет.

Сейчас обработка данных идёт в колоночной SQL БД на одном мощном сервере. Производительность не устраивает (упирается в диск). Предложите мне пожалуйста масштабируемое SQL решение для моей задачи.
По-моему, очень странное решение — гиперпространственное хэширование. Подходит для узкого круга задач (когда нужно уметь быстро искать по любому атрибуту). При этом, т.к. это хэширование, то нельзя делать JOIN по диапазону нескольких атрибутов эффективно (т.е. получить, скажем, все марки автомобилей на рынке с колёсной базой в дипапазоне от 2.5 до 2.7 м и ценой в диапазоне от 750 до 900 тысяч). То есть, хочу быть понят правильно, в Редис этого тоже нельзя, но если индексирование изначально заявлено как *многомерное* то именно такие запросы, на мой взгляд, интересны.

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

Интересно, что они при этом сразу сделали кластер. Их кластерное решение мне кажется любопытным, т.к. они обеспечивают атомарность за счёт записи изменений на несколько узлов кластера. Это правильно, быстрее чем диск, так поступает NDBCluster. Но и памяти это потребляет, по моим представлениям, соответственно.

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

Возможно, я не прав в своих оценках, т.к. потратил на продукт только 30 минут и ушёл пилить Tarantool.

Open Source мир так не живёт, community строится не сразу, особенно в такой насыщенной поляне как NoSQL.

Установил эту базу для тестов по сравнению с Redis. Тесты писал под Python. Итого Hyperdex вставка скачет от 1.5 до 8-10 тысяч операций, redis 23 тысячи операций. Чтение Hyperdex 2300 операций в секунду, redis 23 тысячи. Т.е. redis значительно быстрее.

В целом база интересная, но есть куда развиваться… А тесты судя по всему намеренно завышены.
Sign up to leave a comment.

Articles