Pull to refresh

Comments 35

Познавательно и подробно. Спасибо.
Вы использовали на практике? Сталкивались уже с потерями данных при hinted handoff?
Использую на работе. С потерями данных не сталкивался.
А сколько и каких машин и сколько данных в штуках и в мегабайтах, если не секрет?
5 машин, на них же крутятся заливающие сервисы в пики порядка 300-400 запросов на запись каждый генерирует. Подробней нужно измерить конечно.
имхо, было бы неплохо добавить визуализацию для раздела «Модель данных».
а еще хотелось бы немного подробнее об администрировании кассандры в практ. примерах — но, вероятно, это не входило в задачи этой статьи.
а вообще — спасибо :)
пожалуйста. добавил новую диаграмму про «модель данных».
Super уходит в небытиё. Его заменяет CompositeType
Вот тут хотелось бы поподробней — чем оно лучше, почему заменяет.
Переписал у себя на композитные ключи, действительно быстрее! В 3 раза, т.к. удалось структуру данных оптимизировать
Ставил кассандру, пытался связать ее с rails приложением, однако потерпел фиаско — кассандра (версию не помню, ставил в конце 2011 года) требовала thrift и вот тут оказалась самая главная проблема несовместимости. В итоге бросил и больше не пытался. Мб ситуация изменилась?
Thrift остался. А в чем несовместимость, он же поддерживает Ruby?
Тестировали ее года два назад. Все хорошо, но стабильности не было, в итоге решили не использовать. Потом были новости вроде что facebook отказался от нее, как раз из-за проблем со стабильностью и сложностями в доведении до стабильного состояния.
Года два назад то еще была совсем другая кассандра. А проблемы со стабильностью нужно анализировать. Конечно всегда возникает вопрос о масштабах т.к. в facebook там меганагрузки и возможно они уперлись в какие-то ограничения архитектуры. Не уперлись же они в то, что она не правильно написана или сконфигурирована.
«We found Cassandra's eventual consistency model to be a difficult pattern to reconcile for our new Messages infrastructure.»

тут
Используюте ли вы какие-либо распределенные механизмы для обработки данных?
Используем и они завязаны опять же на кассандру. Больше рассказать не могу.
Даже не скажете, это что-то самописное или какой-нибудь hadoop взят за основу?
Мы пытались использовать hadoop, но он не предназначен для real-time результатов, пришлось писать свой велосипед.
Решение свое и довольно простое, но позволяет поддерживать отказоустойчивость правда не в риалтайме. Для наших нужд хватает.
Объясните, пожалуйста, про согласованность.
Если используется, скажем, ALL+ONE и запись идёт вот прям щас, то как гарантируется, что разные клиенты будут видеть одно и то же состояние?
Согласованность Write=ALL, Read=ONE означает всего-лишь, что после того как операция записи завершится(а она потребует подтверждения всех узлов-реплик), то чтение выполненное после этих всех подтверждений гарантировано вернет эту запись, если бы было Write=ONE, Read=ONE и RF=2 и более например, то это было бы не так — мы дождемся подтверждения на один, а прочитаем с другого. Про разное состояние это возможно вы говорить уже про Atomicity и Isolation, а для них гарантии только на одну запись, то есть на колонки которые связаны одним ключем. Это удается реализовать потому-что они хранятся всегда на серверах которые определяются ключем. ПС Извините за орфографию. В жизни я не такой грамотный :-)
Чтение ключей производится из соответствующего токена или из реплик может читать тоже? read repair не в счет.
Ключ задает пользователь БД когда выполняет запрос.
это понятно. я спрашиваю про другое. есть, например, 5 серверов, по которым пространство ключей «размазано» и зареплицировано в соответствии с реплик фактором. так вот кассандра с одной из этих реплик может прочитать и отдать пользователю данные или она всегда читает только с ноды, на которой «мастер» данные?
Теперь понял. Читается параллельно с ближайших серверов(их количество = read consistiency) из набора узлов-реплик(их количество=replication factor. Например, если у нас строгая согласованность: «read consistiency+write consistiency>=replication factor+1», то такая огранизация, если подумать, будет гарантировать, что прочитается последняя версия.
спасибо, хотел для коллекции изучить Кассандру.
для большего понимания хотелось бы еще примеров разных структур данных:

слишком абстрактно колонка — это по аналогии с РСУБД — стока или все же столбец?
мне кажется, что больше похоже на строку.
Ни то, не другое. В РСУБД это: столбец+значение. Колонки с одним ключом — это записи(record), а в РСУБД строка. Вообще конечно, если совсем не думается про колонки и про то, что в них можно хранить любоую вспомогательную информацию, которая не регулируется схемой, то можно просто представлять таблицу с таймстемпами для значений.
спасибо,
как я понял — это аналог строк в монге
Алексей, а разбирались что происходит, если при записи вычисленная нода-координатор в дауне? В смысле кто и куда запишет данные и реплики, как они будут находиться последующими чтениями по этому ключу и будет ли что-то происходить когда нода-координатор снова поднимется.

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

Ну и раз уж вы тоже используете Кассандру в реальном проекте, у меня есть довольно много практических вопросов — могу писать их потихоньку сюда или еще куда-нибудь. Вам как удобнее?
Only those users with full accounts are able to leave comments. Log in, please.