Pull to refresh

Comments 25

Без проблем. Скажите какая часть Кассандры вас интересует? Хотя оговорюсь, что сам в ней знаю не так уж много.
Да мне, в принципе, все интересно) Рассказывайте о том, что хорошо знаете :)
Расскажите, затронули ли изменения в 2.x счётчики? Работал только с 1.2.6, там счётчики периодически факапили.
С INSERT'ами всё понятно, а что с SELECT'ами, можно ли использовать часть первичного ключа для SELECT? Куда делся или что стало с ordering key, возможно ли теперь задавать составной ordering key?
Счетчики как таковые не изменились, по появилиcь Lightweight transactions и Atomic batches. Не то чтобы это убрало все проблемы счетчиков, но сделало их более надёжным инструментом. Затрону чуток счетчиков в след. статье — №2 — которая уже написана, но ждёт последних правок.

В следующей после следующей статье (№3 по счету) я подробно рассмотрю SELECT, что можно делать, что нельзя и всё такое. Сейчас как раз пишу. Краткий ответ на ваш вопрос — да, с сильным замедлением производительности, но тогда у меня подозрение, что ваша модель могла бы быть лучше.

Ordering key никуда не девался, смотрите чуть выше примеры.

Можно создавать составной ordering key:
CREATE TABLE test1 (name text, id1 int, id2 int, PRIMARY KEY (name, id1, id2)) 
WITH CLUSTERING ORDER BY (id1 DESC, id2 DESC);
Т.е. SELECT так же как и раньше, когда нужно было указывать ALLOW FILTERING?

Да, возможно, что и могла бы быть лучше. У меня хранятся полученные СМС сообщения, с timestamp DESC. Скажем, когда мне нужно получить эти сообщения за какой-то период, приходится использовать ALLOW FILTERING. Никакого основного ключа для кластеризации тут выделить не получается. Тут, скорее, нужна очередь, и Cassandra не очень с таким заданием справляется.

Было бы забавно увидеть что-то типа Cassandra Cookbook, с рецептами что и как лучше делать для типовых задач. Понятно, что для бложика C* подходит слабо.
Похоже я не понял вопроса. Перефразируй. Или просто дождись завтра — я уже написал третью статью про SELECT-ы. Там покрыто всё, что можно было покрыть про слово WHERE.

Что является распределительным (partition) ключом в твой таблице с СМС? Вообще, показал бы уже CREATE таблицs.
Ты думал что будет, если наберётся 2 млрд смс? (У средних опсосов набирается за год или меньше.)

Cookbook для С* может быть и хорошая идея, но такого понятия, как «типовые решения» здесь не cуществует. У всех разные задачи. Даже чуть-чуть отличающаяся задача приводит к совершенно к другим таблицам.

Кстати, вторая статья уже опубликована. habrahabr.ru/post/204026/
Синтетический там int, пробовал дату (без времени), но только усложняет логику приложения:
CREATE TABLE messages (
    constant int,
    timestamp timestamp,
    body varchar,
    sender varchar,
    recipient varchar,
    weekday int,
    PRIMARY KEY (constant, timestamp)
)
    WITH CLUSTERING ORDER BY (timestamp ASC);


Вообще расчёт на 100к в секунду в пике, это получается куда больше. Данные эти нужны, но пакетным обработчиком партиями выбираются и кладутся в другое место. То есть тут можно и TTL применить, у меня в INSERT'ах стоит месяц.
Усложнение приложение — неизбеждая часть, если хочется скорости. Поэтому рекомендую усложнять.

Как я писал в статье, вам нужно сначала определиться с теми SELECT-ами, которые планируете делать, и только потом уже моделировать таблицы. В связи с чем вопрос: какие select-ы по этой таблице вам нужно делать?
Ага, понял о чём речь в вопросе про 2 млрд смс. Придётся переделывать схему.
Очень неплохо, спасибо!
бинарный и довольно сложный язык Thrift.


Thrift скорее rpc протокол, чем язык.
Да, я знаю. Здесь, на самом деле, я довольно много неправильных терминов называл. Это ради простоты. Новичков не хотелось сильно нагружать.
Интересно. Но единственное что не понятно, почему в Касандре пытаются применить ОЧЕНЬ похожий на реляционный TSQL язык CQL.
У NOSQL свой путь и, имхо, не надо работу с ней делать похожим на всем угодный TSQL ;) Это приводит к тому что многие пытаются думать реляционно в nosql средах.
Урезанный SQL гораздо проще воспринимается чем thift api.
С одной стороны всё верно, люди начинают применять SQL модель к Кассандре.
Но с другой стороны переход с SQL на CQL сильно упрощается (thrift имеет высокий порог входа).
Люди продвигающие CQL утверждают, что Кассандра стала более популярной именно благодаря CQL.
Уххх ты как интересно! Мне как sql-щику интересно исключительно. Запросы, запросы покажите. Пример с датчиками прекрасен, но он только один. Как я понял, джойнов не бывает (в этом вроде бы и смысл) — а что бывает? Ограничения? Сортировки? Группировки?

Не знаю, получилось у меня внятно высказаться или нет. На всякий случай — у меня и в мыслях нет доказывать, что «Cassandra — это неправильный дизайн данных». Я убеждён, что это *правильный* дизайн, но мне совершенно не знакомый, и хочу узнать больше про эту часть реальности.

В общем, спасибо за статью, пишите ещё. Пошёл смотреть вебинары :).
После просмотра вебинаров вопросы отпадут сами собой. :) Там куча примеров.
Но следующая статья уже запланирована. Надеюсь родить через недельку.
А порядок в составном ключе и кластерном влияет на алгоритм распределения?
Т.е если ( (A,B), C, D) и ( (B, A), D, C) с точки зрения запроса и их порядков и возможностей понятно, а вот будет ли идентичен алгоритм заполнения?
Порядок очень влияет. Грубо говоря, дерево объектов будет иметь вершину А в первом случае, и B во втором. Гляньте третью статью цикла. Там будет понятно почему так.
Если у нас к примеру 5-6 распределительных ключей и 5-6 класстерных, и еще 4-5 обычных колонок.
Сильно ли пострадает производительность записи и чтения? На сколько процентов примерно
:) Не знаю. Я пока не гуру. Перфоманс таких таблиц не замерял. :)
Атомарность и изоляция отсутствуют как и в большинстве NoSQL?
Изоляция присутствует на уровне строки, но не БД в целом. Она же распределённая. :)
Атомарность есть — Lightweight Transactions — это микротранзакции.
Учтите, что бонус С* не в автомарности, а в распределённости. Для больших проектов на сотни нод С* — идеальное решение.
Only those users with full accounts are able to leave comments. Log in, please.