Комментарии 15
Спасибо за статью, а можно раз уж затронули CockroachDB, опубликовать в чем именно не оправдались пожелания по производительности, какими они были и что ответили разработчики на ваши запросы?
DynamoDB не смотрели? Или вам строго on-prem нужно?
Они не предоставляют сервис во всех странах, где нам нужно хранить персональные данные (например, в России). Кроме того, есть риск зависимости от одного облачного поставщика.
Когда мы используем какие-то сервисы от Amazon/Azure/Google/Yandex/Mail.ru, то всегда смотрим, что сможем найти аналогичные по приемлемым ценам от других облачных провайдеров. В случае DynamoDB это была бы слишком сильная привязка к Amazon.
Когда мы используем какие-то сервисы от Amazon/Azure/Google/Yandex/Mail.ru, то всегда смотрим, что сможем найти аналогичные по приемлемым ценам от других облачных провайдеров. В случае DynamoDB это была бы слишком сильная привязка к Amazon.
На первый взгляд напоминает улучшенную версию Кассандры.
Статья именно что первый взгляд. Без тестов это просто еще одна KV бд.
Да, она реализует CP, а не AP как многие другие. И транзакции есть вроде. Но вопрос — насколько они тормозят?
Впрочем, если можно прожить без транзакций, с AP (вместо CP) и без сортировки ключей — то быстрее aerospike еще ничего больше не видел.
В любом случае, спасибо за статью — будет свободное время, поставлю в ДЦ и потестирую
Да, она реализует CP, а не AP как многие другие. И транзакции есть вроде. Но вопрос — насколько они тормозят?
Впрочем, если можно прожить без транзакций, с AP (вместо CP) и без сортировки ключей — то быстрее aerospike еще ничего больше не видел.
В любом случае, спасибо за статью — будет свободное время, поставлю в ДЦ и потестирую
В Youtube есть виде с тестами
Да и на сайте разработчика есть тесты. Ну да ладно, все равно всегда надо под свой профиль нагрузки выбирать. И тестить самому.
Но циферки хорошие в документации написаны.
Хотя я больше люблю AP использовать. Бизнесс-процессы позволяют неконсистентность. А вот падение ноды бывает не так уж часто. Из-за дисков, как правило. И мне нравится, что пока нода поднимается, аэроспайк запись работает как ни в чем не бывало. Но с просадкой по латнеси, конечно
Но циферки хорошие в документации написаны.
Хотя я больше люблю AP использовать. Бизнесс-процессы позволяют неконсистентность. А вот падение ноды бывает не так уж часто. Из-за дисков, как правило. И мне нравится, что пока нода поднимается, аэроспайк запись работает как ни в чем не бывало. Но с просадкой по латнеси, конечно
До продаже её Apple был ещё слой SQL
> У FoundationDB есть уникальное преимущество — автоматический решардинг.
ЕМНИП Эластиксерч тоже это умеет. Не то чтоб это прям уж очень уникальное преимущество.
ЕМНИП Эластиксерч тоже это умеет. Не то чтоб это прям уж очень уникальное преимущество.
Мы в Pyrus довольно активно используем ElasticSearch. И, к сожалению, нет, он не умеет автоматически решардить.
ElasticSearch обычно использует _routing в качестве ключа для определения шарды по конкретному документу. И изменить позже количество шард является невыполнимой задачей, так как связано с переиндексированием всех документов, так как под каждой шардой прячетя индекс Lucene.
В elastic 6 добавили более функциональный механизм split (а в 7 станет более функциональным), позволяющий разделить одну шарду на несколько, что впрочем тоже связано с временным ограничением в записи, а также созданием нового индекса.
Также есть более старый механизм rollover, который позволяет лишь автоматическое создавать новые индексы под одним alias. Что впрочем пригодно в основном для записи логов, но меньше для динамически изменяющегося индексируемого контента.
И тот и другой подход применимы и имеют право на жизнь, но это совсем не то, что хочется называть автоматическим решардингом.
ElasticSearch обычно использует _routing в качестве ключа для определения шарды по конкретному документу. И изменить позже количество шард является невыполнимой задачей, так как связано с переиндексированием всех документов, так как под каждой шардой прячетя индекс Lucene.
В elastic 6 добавили более функциональный механизм split (а в 7 станет более функциональным), позволяющий разделить одну шарду на несколько, что впрочем тоже связано с временным ограничением в записи, а также созданием нового индекса.
Также есть более старый механизм rollover, который позволяет лишь автоматическое создавать новые индексы под одним alias. Что впрочем пригодно в основном для записи логов, но меньше для динамически изменяющегося индексируемого контента.
И тот и другой подход применимы и имеют право на жизнь, но это совсем не то, что хочется называть автоматическим решардингом.
Ок, спасибо за объяснение. Я знаю, что увеличить к-во основных шард одного индекса не простая задача. Но при добавлении нового узла, ES сможет перетащить старый шард (или его реплику) на новый сервер, таким образом освободив место на старом сервере. Что в общем можно назвать решардингом, в моем понимании. Это вполне себе решение, если в дальнейшем создавать новые индексы и вариант горизонтального масштабирования.
Спасибо за статью! Выглядит очень интересно, чтобы узнать о ней подробнее.
Будет здорово, если поделитесь потом вашими тестами.
Например, авторы CockroachDB уже шли этим путем — сделав слой SQL поверх RocksDB (локальный key value store) и получили проблемы производительности, присущие реляционным джойнам.
Очень странное заключение. Тут проблема не в том что они используют kv store, (так как это делают многие реляционные бд, например движок для mysql myrocks использует rocksdb и довольно шустро работает), а проблема именно в том как сделать эффективно распределенный join. И не важно как вы храните данные под капотом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Первый взгляд на FoundationDB, открытую Apple