Comments 32
С виду вроде штука вроде интересная, надо будет поиграться на досуге.
Напоминает обычный memcache, со своей либой для выбора сервера данных, или еще лучше — memcacheq или memcachedb.
Отличий о memcache очень много, начиная от того, что Riak хранит данные не в памяти а на жестких дисках, и заканчивая упором на fault tolerance (отказоустойчивость). Они схожи в одном — оба NoSQL продукты.
memcacheq тоже складывает всё на диск в berkleydb, и при ребуте восстанавливает «куда надо».
Riak — это некий велосипед для тех, кто не может построить его из уже существующих решений.
Riak — это некий велосипед для тех, кто не может построить его из уже существующих решений.
У обоих продуктов разные цели. Riak направлен на то чтобы дать возможность разработчикам сделать массивные продукты с максимальной отказоустойчивостью. memcacheq — это система очередей, а не хранения данных. Врятли с ее помощью мы сможем организовать систему которая сможет хранить несколько десятков терабайт данных, и предоставлять при этом Map/Reduce функциональность.
Riak — это не велосипед, это скорее санки. Когда все изобретали велосипеды, ребята и basho (бывшие разработчики из Akamai) поставили себе сделать отказоустойчивую систему, исследовали возможности и уже готовые реализации, дабы не ходить по граблям. Я не говорю что система идеальна, но поверьте, она заслуживает внимания, если вы занимаетесь разработкой больших проектов.
Riak — это не велосипед, это скорее санки. Когда все изобретали велосипеды, ребята и basho (бывшие разработчики из Akamai) поставили себе сделать отказоустойчивую систему, исследовали возможности и уже готовые реализации, дабы не ходить по граблям. Я не говорю что система идеальна, но поверьте, она заслуживает внимания, если вы занимаетесь разработкой больших проектов.
Отказоустойчивость строится не только на программной среде. Достаточно одного гвоздя в винчестер, чтобы убить даже мастер-сервер. А гвоздями могут быть и питание по 1й категории, и резервные каналы и всё, что стоит до и после Riak.
В статье идет упор, что это отказоустойчивое решение, а не приложение. Получается, они установкой одной софтины гарантируют отказоусточивость всех компонентов, даже рубильника в серверной — что если его дёрнуть, аплинки не выключатся и все ноды будут отвечать на запросы…
В статье идет упор, что это отказоустойчивое решение, а не приложение. Получается, они установкой одной софтины гарантируют отказоусточивость всех компонентов, даже рубильника в серверной — что если его дёрнуть, аплинки не выключатся и все ноды будут отвечать на запросы…
Отказоустойчивость строится не только на программной среде.
Отказоустойчивость строится не только на программной среде. Достаточно одного гвоздя в винчестер, чтобы убить даже мастер-сервер. А гвоздями могут быть и питание по 1й категории, и резервные каналы и всё, что стоит до и после Riak.
1. Мастре сервера в системе нет. Это p2p.
2. Мы говорим об организации отказоустойчивости с помощью архитектуры проекта, конечно если на датацентр упадет метеорит, это вас не спасет.
Получается, они установкой одной софтины гарантируют отказоусточивость всех компонентов, даже рубильника в серверной — что если его дёрнуть, аплинки не выключатся и все ноды будут отвечать на запросы…
Вы думаете сейчас на уровне системы с 10-20 серверами. Это решение для больших систем, прям БОЛЬШИХ. >100 серверов. Когда сервера стоят в разных датацентрах в разных странах. На меньших объемах это решение в общем не нужно. Можно использовать MySQL с репликацией и MySQL Proxy.
Ну если уж вы мне не верите, посмотрите на Cassandra, эта аналогичная система используемая в Facebook. Вот ресурсы которые она использует:
The system currently stores TB’s of indexes across a cluster of 600+ cores and 120+ TB of disk space.
Для разнесенных серверов по странам встает вопрос об актуальности данных на всех серверах. Даже Mysql-репликация может лагать — оптимально 1-2 секунды на тяжелые запросы, но ведь каналы могут падать и актуальность таких данных под вопросом.
Riak не панацея от всех проблем, связанных с доступностью и актуальностью данных.
Riak не панацея от всех проблем, связанных с доступностью и актуальностью данных.
Что-то вас понесло уже совсем в другую сторону.
Было бы здорово увидеть пару рабочих примеров. Не тестовых, а которые используются непосредственно в работе.
Ну и производительность, конечно.
Ну и производительность, конечно.
Тут наверно нужно понять что в данном подходе главное масштабируемость и отказоустойчивость.
К сожалению их не так много. В основном из общения с разработчиками в списке рассылки я понял, что на данный момент есть только один большой кластер Riak — у самих разработчиков. Тесты и свои впечатления от работы с системой, я постараюсь выложить в следующих статьях. Кстати я забыл упоминуть в статье о том, что система <a href="http://www.basho.com/enterpriseds.html""">рассчитана на рынок Enterprise платформ.
Статья познавательная. Спасибо.
Но я поражаюсь, как легко многие жертвуют целостностью.
Отказ от целостности — это битые данные, глюки и жалобы пользователей.
ИМХО на нетранзакционные хранилища можно переходить, только имея за плечами опыт работы с ACID-транзакционными базами данных, зная что значит каждая буковка в слове ACID и что она дает.
Но я поражаюсь, как легко многие жертвуют целостностью.
Отказ от целостности — это битые данные, глюки и жалобы пользователей.
ИМХО на нетранзакционные хранилища можно переходить, только имея за плечами опыт работы с ACID-транзакционными базами данных, зная что значит каждая буковка в слове ACID и что она дает.
Всегда пожалуйста :)
Могу сказать почему. Реализация контроля целостности, более легкая задача. Для отказоустойчивости в большинстве случаев нужна продуманная и серьезная архитектура. Контроль целостности реализовать проще. Для контроля целостности можно использовать избыточность данных и хэши сообщений (проверка хэша сообщение и в случае повреждения либо повторный запрос либо получение с другого сервера). Но как сказано в статье можно выбрать всего 2 пункта из трех.
Абсолютно согласен. Я бы еще посоветовал при использовании той или иной технологии, обдумывать какие фичи из нее вам нужны и расставить им приоритеты.
Но я поражаюсь, как легко многие жертвуют целостностью.
Могу сказать почему. Реализация контроля целостности, более легкая задача. Для отказоустойчивости в большинстве случаев нужна продуманная и серьезная архитектура. Контроль целостности реализовать проще. Для контроля целостности можно использовать избыточность данных и хэши сообщений (проверка хэша сообщение и в случае повреждения либо повторный запрос либо получение с другого сервера). Но как сказано в статье можно выбрать всего 2 пункта из трех.
на нетранзакционные хранилища можно переходить, только имея за плечами опыт работы с ACID-транзакционными базами данных
Абсолютно согласен. Я бы еще посоветовал при использовании той или иной технологии, обдумывать какие фичи из нее вам нужны и расставить им приоритеты.
блин, сколько можно, не «вэб», а «веб».
UFO just landed and posted this here
Нет, в начале есть фраза: «Riak — это документно-ориентированная база данных.» Суть в том, что вы можете сами выбирать как использовать систему. Можно как key-value хранилище, а можете как документно-ориентированную базу данных (основных баз такого типа на данный момент 3 — Riak, CouchDB и MongoDB).
Нет, я именно имею ввиду документо-ориентированную базу данных.
Тут я описал базовый функционал. На сайте разработчиков есть список всех фичерсов системы.
Насчет сравнения, думаю написать в следующей статье перевод интересного сравнения всех NoSQL систем.
Тут я описал базовый функционал. На сайте разработчиков есть список всех фичерсов системы.
Насчет сравнения, думаю написать в следующей статье перевод интересного сравнения всех NoSQL систем.
Я что-то не до конца понял про репликацию. В списке фич есть такая строчка «Masterless multi-site replication» для Enterprise-версии. Разве репликация не предполагается самим принципом, который вы описали (N, R и W)? Или это что-то другое?
И ещё: сколько стоит Enterprise-версия или хотя бы от чего зависит цена?
И ещё: сколько стоит Enterprise-версия или хотя бы от чего зависит цена?
Разве репликация не предполагается самим принципом, который вы описали (N, R и W)?
Это репликация внутри кластера, в Enterprise версии есть поддержка межкластерной репликации данных. Это в основном нужно если кластеры в разных гео зонах.
сколько стоит Enterprise-версия или хотя бы от чего зависит цена?
Честно скажу, этого я не знаю.
В таком случае другой вопрос: схема обеспечения целостности данных, описанная в топике, подразумевала репликацию внутри кластера или платную межкластерную репликацию? Просто вы оперировали как раз географически удалёнными узлами.
В статье шла речь о целостности данных внутри кластера. Межкластерная репликация как пишут сам разработчики нужна в случае если вы хотите сделать несколько кластеров read-only (простейший пример CDN) или для бекапов.
Т.е. получается, что можно настроить кластер так?: разделяем узлы на две половинки, одну половинка находится в датацентре A, другая — в датацентре B, и говорим riak'у, что он должен сделать так, чтобы на обоих половинках были полные данные? Можно?
Если можно, то тогда непонятно, зачем нужна межкластерная репликация, если ту же функциональность можно обеспечечить и средствами одного кластера и бесплатно (просто не писать в одну из половинок).
Если можно, то тогда непонятно, зачем нужна межкластерная репликация, если ту же функциональность можно обеспечечить и средствами одного кластера и бесплатно (просто не писать в одну из половинок).
Конечно можно.
Вот простейший пример когда это нужно: у вас есть 2 кластера — продакшен и деплоймент. В продакшене хранятся и накапливаются данные используемые для обработки (скажем сторонние клиенты предоставляют вам данные). При разработке вам нужны эти данные, для тестов или для проверки, но вы сами понимаете делать это с данными находящимися в продакшене вам никто не даст, и правильным решением тут выступает именно репликация продакшен кластера на деплоймент.
Вот простейший пример когда это нужно: у вас есть 2 кластера — продакшен и деплоймент. В продакшене хранятся и накапливаются данные используемые для обработки (скажем сторонние клиенты предоставляют вам данные). При разработке вам нужны эти данные, для тестов или для проверки, но вы сами понимаете делать это с данными находящимися в продакшене вам никто не даст, и правильным решением тут выступает именно репликация продакшен кластера на деплоймент.
хорошая статья и правильный рекрутинг, так держать! ;)
> Однако вы разрабатываете аппликации
Даже промпт перевел бы «приложения»
Даже промпт перевел бы «приложения»
Sign up to leave a comment.
Riak — веб-ориентированная система хранения данных