Перевод набора данных / запросов MySQL в эквивалентное представление Cassandra - PullRequest
Новая
       13

Перевод набора данных / запросов MySQL в эквивалентное представление Cassandra

4 голосов
/ 10 марта 2010

Рассмотрим таблицу MySQL на 500 миллионов строк со следующей структурой таблицы ... 

CREATE TABLE foo_objects (
  id int NOT NULL AUTO_INCREMENT,
  foo_string varchar(32),
  metadata_string varchar(128),
  lookup_id int,
  PRIMARY KEY (id),
  UNIQUE KEY (foo_string),
  KEY (lookup_id),
);

... который запрашивается с использованием только следующих двух запросов ... 

# lookup by unique string key, maximum of one row returned
SELECT * FROM foo_objects WHERE foo_string = ?;
# lookup by numeric lookup key, may return multiple rows
SELECT * FROM foo_objects WHERE lookup_id = ?;

Учитывая эти запросы, как бы вы представили данный набор данных с помощью Cassandra?

1 Ответ

2 голосов
/ 11 марта 2010

у вас есть два варианта:

(1) является своего рода традиционным: иметь один CF (columnfamily) с вашими объектами foo, одну строку на foo, один столбец на поле. затем создайте два индексных CF, где ключ строки в одном - это строковые значения, а ключ строки в другом - lookup_id. Столбцы в строках индекса являются идентификаторами. Таким образом, вы делаете GET для индекса CF, а затем возвращаете MULTIGET для идентификаторов.

Обратите внимание, что если вы можете сделать id таким же, как lookup_id, у вас будет на один индекс меньше для поддержки.

Клиенты высокого уровня, такие как lazyboy Дигга (http://github.com/digg/lazyboy), будут автоматизировать ведение индекса CF для вас. Сама Кассандра не делает этого автоматически (пока).

(2) аналогично (1), но вы дублируете все объекты foo в подколонки строк индекса (то есть столбцы верхнего уровня индекса являются суперколонками). Если вы на самом деле не запрашиваете сам идентификатор foo, вам вообще не нужно хранить его в собственном CF.

...