Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 50
А какие у него требования к памяти? Может ли работать со своим пространством, не загружая его целиком в память?
Статья мутно-маркетинговая. Кто понял, расскажите, в
чем отличие от известных приемов запихивания атрибутов
в биты ключа, как это делает instagram, например.
чем отличие от известных приемов запихивания атрибутов
в биты ключа, как это делает instagram, например.
Олег, уж с вашей специализацей, опытом и, наверняка, знанием английской технической терминологии -, уверен, не составит труда прочитать всего 15 страниц полного описания + есть ссылка на патент + доступны исходники. И, вместо проявления неуважения к чужому труду, могли бы дать оценку проекту как специалист по базам данных.
Топик — вводный. Авторы заявили о проекте в широкие массы только вчера.
Топик — вводный. Авторы заявили о проекте в широкие массы только вчера.
А с массивами оно работать умеет? перерыл сайт их инфы не нашёл.
Странное сравнение HyperDex с Cassandra и MongoDB — они же все три разные.
Кассандра при этом древнейшая
Тоже удивило, учитывая количество оптимизаций по производительности в 1.x версиях очень это подозрительно. Один только read repair убивает в ванильной 0.7.3 производительность по чтению сильно.
И вообще Cassandra оптимизирована на быструю запись, не понятно зачем с ней сравнивать решение оптимизированное на быстрое чтение…
И вообще Cassandra оптимизирована на быструю запись, не понятно зачем с ней сравнивать решение оптимизированное на быстрое чтение…
База где хранится, в RAM или на диске?
Каково потребление RAM и процессора в сравнении с конкурентами?
Как происходит работа с процессором, атомарно как в редис(из чего вытекает что 1 инстанс — 1 ядро), или многопоточно?
Каково потребление RAM и процессора в сравнении с конкурентами?
Как происходит работа с процессором, атомарно как в редис(из чего вытекает что 1 инстанс — 1 ядро), или многопоточно?
А клиенты увы, пока только под C++, Java, Python…
правильнее было бы с редисом сравнивать, а не с монгой
Они считают раз 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 или подобное решение скоро переедет на него.
В HyperDex value-поиск есть и я не удивлюсь, если Resque или подобное решение скоро переедет на него.
Господи, нет термина субпространство, бывает подпространство.
Нет информации о протоколе, транзакциях, реакцию на сбой в сети.
Нет версии под Windows.
Клиентские библиотеки только под C, C + + и Python.
Я просто сейчас ищу себе NoSQL базу и эти моменты мне важны, буду смотреть за этой базой но сейчас использовать не буду.
Нет версии под Windows.
Клиентские библиотеки только под C, C + + и Python.
Я просто сейчас ищу себе NoSQL базу и эти моменты мне важны, буду смотреть за этой базой но сейчас использовать не буду.
Очень жаль, что вы не сможете использовать эту базу. Но очень хорошо, что вы описали причины вашего решения. Я уверен, разработчики обязательно зайдут на хабрахабр и сделают всё, чтобы исправить описанные вами проблемы и недостатки.
ИМХО любая база данных должна пройти стадию созревания в несколько лет. Молодые базы могут быть очень нестабильны
Плохой подход. Вы своему коду тоже даёте полежать несколько лет перед тем, как отправить его в продакшен?
Потестите у себя — если минусов больше, то не используйте.
Или хотите сказать MySQL и ничего больше сейчас? Если да, то назову несколько задач, с которыми Redis справится на несколько порядков эффективнее, хотя этой базе нет нескольких лет.
Потестите у себя — если минусов больше, то не используйте.
Или хотите сказать MySQL и ничего больше сейчас? Если да, то назову несколько задач, с которыми Redis справится на несколько порядков эффективнее, хотя этой базе нет нескольких лет.
Вы все воспринимаете буквально? Оптимальное решение задач это только одна причина. Еще есть:
У успешных продуктов это появляется со временем, а плохие просто умирают. Цикл времени может быть разным, но я для себя вывел несколько лет.
- наличие вменяемой документацией
- консистентность данных
- наличие 3rd-party тулзов
- комьюнити саппорт
- цикл релизов
- поддержка различных языков
У успешных продуктов это появляется со временем, а плохие просто умирают. Цикл времени может быть разным, но я для себя вывел несколько лет.
По статье непонятно чем это отличается от разряженных многомерных массивов.
Странно, что в обсуждении ни разу не упоминается OLAP.
Призываю в топик Костю Осипова :-)
Обсуждение и критика бенчмарков в рассылке Redis: groups.google.com/group/redis-db/browse_thread/thread/378a32de50a782c5 (на английском)
Судя по алгоритму работы, на запросах с полнотекстовым поиском HyperDex подпросядет до уровня остальных БД, если не ниже, следовательно круг использования сужается, до фаст-фуд-сервисов, а-ля тумблер, твиттер.
Вам не кажется, что вы сильно завышаете необходимость полнотекста?
А ещё мне кажется, что ошиблись в примерах. Как раз на том же твиттере и тумблере полнотекст может быть необходим.
А ещё мне кажется, что ошиблись в примерах. Как раз на том же твиттере и тумблере полнотекст может быть необходим.
Нет, не сильно завышаю. Если бы вы сталкивались с системами документооборота, то не задавали бы таких вопросов.
И опять же для сервисов использующих модель быстро устаревающего контента полнотекстовый поиск заменяется рубрикацией, тегами и тематической группировкой, чаще всего этого более чем достаточно. Тумблер, например, не использует полнотекстовый поиск как таковой.
Я лишь уточнил, что не стоит смотреть на синтетические бенчмарки, приведенные без детального описания правил тестирования. Лучше проанализировать поведение и на основании этого делать выводы в какую нишу метит новичок. А сравнивать теплое с мягким знаете ли…
И опять же для сервисов использующих модель быстро устаревающего контента полнотекстовый поиск заменяется рубрикацией, тегами и тематической группировкой, чаще всего этого более чем достаточно. Тумблер, например, не использует полнотекстовый поиск как таковой.
Я лишь уточнил, что не стоит смотреть на синтетические бенчмарки, приведенные без детального описания правил тестирования. Лучше проанализировать поведение и на основании этого делать выводы в какую нишу метит новичок. А сравнивать теплое с мягким знаете ли…
А я вот знанимаюсь не документооборотом, а аналитикой и статистикой. И анализ текста в 95% случаев мне совершенно не нужен, а вот к распределённым хранилищам у меня есть большой интерес. Так что ваша классификация «круг использования сужается, до фаст-фуд-сервисов» мне кажется неверной.
Неужели вы считаете, что например, астрономы обрабатывающие полученные данные — «фастфуд»?
Неужели вы считаете, что например, астрономы обрабатывающие полученные данные — «фастфуд»?
Если вы обрабатываете однотипные данные, то для этого был создан SQL. А распределенные хранилища не самоцель: вы их хоть на файлах можете организовать.
Предложите мне пожалуйста распределённое SQL хранилище для сбора и анализа различных статистических срезов по пользователям и их активности. В хранилище, допустим, я положу сущность profile и click. Profile — суть таблица Users, click — суть access_log. И вот я хочу найти самое активное время для американцев возрастом 36-48 лет.
Сейчас обработка данных идёт в колоночной SQL БД на одном мощном сервере. Производительность не устраивает (упирается в диск). Предложите мне пожалуйста масштабируемое SQL решение для моей задачи.
Сейчас обработка данных идёт в колоночной SQL БД на одном мощном сервере. Производительность не устраивает (упирается в диск). Предложите мне пожалуйста масштабируемое SQL решение для моей задачи.
По-моему, очень странное решение — гиперпространственное хэширование. Подходит для узкого круга задач (когда нужно уметь быстро искать по любому атрибуту). При этом, т.к. это хэширование, то нельзя делать JOIN по диапазону нескольких атрибутов эффективно (т.е. получить, скажем, все марки автомобилей на рынке с колёсной базой в дипапазоне от 2.5 до 2.7 м и ценой в диапазоне от 750 до 900 тысяч). То есть, хочу быть понят правильно, в Редис этого тоже нельзя, но если индексирование изначально заявлено как *многомерное* то именно такие запросы, на мой взгляд, интересны.
Сравнение в этом ключе со всеми остальными базами мне кажется мало уместным, т.к. у конкурентов будет профиль по потреблению памяти совсем другой (индексы по каждому атрибуту таки требуют памяти).
Интересно, что они при этом сразу сделали кластер. Их кластерное решение мне кажется любопытным, т.к. они обеспечивают атомарность за счёт записи изменений на несколько узлов кластера. Это правильно, быстрее чем диск, так поступает NDBCluster. Но и памяти это потребляет, по моим представлениям, соответственно.
Всё что происходит очень похоже на способ маркетинга стартапа, т.к сразу готов сайт, бенчмарки, списки рассылки и т.п., о преимуществах они говорят, а о недостатках и ограничениях предоставляют сообществу сделать вывод самостоятельно.
Возможно, я не прав в своих оценках, т.к. потратил на продукт только 30 минут и ушёл пилить Tarantool.
Open Source мир так не живёт, community строится не сразу, особенно в такой насыщенной поляне как NoSQL.
Сравнение в этом ключе со всеми остальными базами мне кажется мало уместным, т.к. у конкурентов будет профиль по потреблению памяти совсем другой (индексы по каждому атрибуту таки требуют памяти).
Интересно, что они при этом сразу сделали кластер. Их кластерное решение мне кажется любопытным, т.к. они обеспечивают атомарность за счёт записи изменений на несколько узлов кластера. Это правильно, быстрее чем диск, так поступает NDBCluster. Но и памяти это потребляет, по моим представлениям, соответственно.
Всё что происходит очень похоже на способ маркетинга стартапа, т.к сразу готов сайт, бенчмарки, списки рассылки и т.п., о преимуществах они говорят, а о недостатках и ограничениях предоставляют сообществу сделать вывод самостоятельно.
Возможно, я не прав в своих оценках, т.к. потратил на продукт только 30 минут и ушёл пилить Tarantool.
Open Source мир так не живёт, community строится не сразу, особенно в такой насыщенной поляне как NoSQL.
Установил эту базу для тестов по сравнению с Redis. Тесты писал под Python. Итого Hyperdex вставка скачет от 1.5 до 8-10 тысяч операций, redis 23 тысячи операций. Чтение Hyperdex 2300 операций в секунду, redis 23 тысячи. Т.е. redis значительно быстрее.
В целом база интересная, но есть куда развиваться… А тесты судя по всему намеренно завышены.
В целом база интересная, но есть куда развиваться… А тесты судя по всему намеренно завышены.
Думаю, вам стоит отписаться о своих результатах на их страничке на гитхабе с подробным описанием как вы проводили тесты.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HyperDex — новое опенсорсное NoSQL key-value хранилище, заточенное на очень быстрый поиск