Comments 35
Познавательно и подробно. Спасибо.
Вы использовали на практике? Сталкивались уже с потерями данных при hinted handoff?
В чем рисовали диаграммы?
имхо, было бы неплохо добавить визуализацию для раздела «Модель данных».
а еще хотелось бы немного подробнее об администрировании кассандры в практ. примерах — но, вероятно, это не входило в задачи этой статьи.
а вообще — спасибо :)
а еще хотелось бы немного подробнее об администрировании кассандры в практ. примерах — но, вероятно, это не входило в задачи этой статьи.
а вообще — спасибо :)
пожалуйста. добавил новую диаграмму про «модель данных».
Про SuperColumnFamily хорошо бы еще :)
Super уходит в небытиё. Его заменяет CompositeType
Вот тут хотелось бы поподробней — чем оно лучше, почему заменяет.
1. скорость работы ниже
2. CQL не поддерживает его и не будет
stackoverflow.com/questions/11915255/why-are-super-columns-in-cassandra-no-longer-favoured
www.quora.com/Cassandra-database/Why-is-it-bad-to-use-supercolumns-in-Cassandra
2. CQL не поддерживает его и не будет
stackoverflow.com/questions/11915255/why-are-super-columns-in-cassandra-no-longer-favoured
www.quora.com/Cassandra-database/Why-is-it-bad-to-use-supercolumns-in-Cassandra
Ставил кассандру, пытался связать ее с rails приложением, однако потерпел фиаско — кассандра (версию не помню, ставил в конце 2011 года) требовала thrift и вот тут оказалась самая главная проблема несовместимости. В итоге бросил и больше не пытался. Мб ситуация изменилась?
Тестировали ее года два назад. Все хорошо, но стабильности не было, в итоге решили не использовать. Потом были новости вроде что facebook отказался от нее, как раз из-за проблем со стабильностью и сложностями в доведении до стабильного состояния.
Года два назад то еще была совсем другая кассандра. А проблемы со стабильностью нужно анализировать. Конечно всегда возникает вопрос о масштабах т.к. в facebook там меганагрузки и возможно они уперлись в какие-то ограничения архитектуры. Не уперлись же они в то, что она не правильно написана или сконфигурирована.
«We found Cassandra's eventual consistency model to be a difficult pattern to reconcile for our new Messages infrastructure.»
тут
тут
Используюте ли вы какие-либо распределенные механизмы для обработки данных?
Объясните, пожалуйста, про согласованность.
Если используется, скажем, ALL+ONE и запись идёт вот прям щас, то как гарантируется, что разные клиенты будут видеть одно и то же состояние?
Если используется, скажем, 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), а в РСУБД строка. Вообще конечно, если совсем не думается про колонки и про то, что в них можно хранить любоую вспомогательную информацию, которая не регулируется схемой, то можно просто представлять таблицу с таймстемпами для значений.
Алексей, а разбирались что происходит, если при записи вычисленная нода-координатор в дауне? В смысле кто и куда запишет данные и реплики, как они будут находиться последующими чтениями по этому ключу и будет ли что-то происходить когда нода-координатор снова поднимется.
Вопрос возник из того, что у вас в тексте неск раз проскальзывает, что нода-координатор для ключа может и не быть одной из нод-реплик (чего я не знал). Интересно понять все варианты, когда такая ситуация возникает и как это собственно работает.
Ну и раз уж вы тоже используете Кассандру в реальном проекте, у меня есть довольно много практических вопросов — могу писать их потихоньку сюда или еще куда-нибудь. Вам как удобнее?
Вопрос возник из того, что у вас в тексте неск раз проскальзывает, что нода-координатор для ключа может и не быть одной из нод-реплик (чего я не знал). Интересно понять все варианты, когда такая ситуация возникает и как это собственно работает.
Ну и раз уж вы тоже используете Кассандру в реальном проекте, у меня есть довольно много практических вопросов — могу писать их потихоньку сюда или еще куда-нибудь. Вам как удобнее?
Sign up to leave a comment.
Как устроена apache cassandra