Почему многие называют Cassandra базой данных, ориентированной на столбцы?
прочитав несколько статей и документов в сети Интернет, я нашел много противоречивой информации о модели данных Cassandra. Многие идентифицируют его как базу данных, ориентированную на столбцы, другие-как базу данных, ориентированную на строки, а затем определяют его как гибридный способ того и другого.
согласно тому, что я знаю о том, как Кассандра хранит файл, он использует *-индекс.db файл для доступа в правильном положении * - данных.db файл, где он хранится фильтр цветения, индекс столбца, а затем столбцы требуемой строки.
на мой взгляд, это строго ориентировано на строки. Я что-то упускаю?
5 ответов
да," колонка-ориентированная " терминология немного запутана.
модель в Cassandra заключается в том, что строки содержат столбцы. Для доступа к наименьшей единице данных (столбцу) необходимо указать сначала имя строки (ключ), затем имя столбца.
так в колонке семейство называется Fruit
у вас может быть структура, как в следующем примере (с 2 строками), где типы фруктов являются ключами строк, а столбцы имеют имя и значение.
apple -> colour weight price variety
"red" 100 40 "Cox"
orange -> colour weight price origin
"orange" 120 50 "Spain"
один отличие от табличной реляционной базы данных заключается в том, что в любой момент можно опустить столбцы (оранжевый не имеет разнообразия) или добавить произвольные столбцы (оранжевый имеет происхождение). Вы все еще можете представить данные выше как таблицу, хотя и разреженную, где многие значения могут быть пустыми.
однако" ориентированная на столбец " модель также может использоваться для списков и временных рядов, где каждое имя столбца уникально (и здесь у нас есть только одна строка, но у нас могут быть тысячи или миллионы колонки):
temperature -> 2012-09-01 2012-09-02 2012-09-03 ...
40 41 39 ...
который сильно отличается от реляционной модели, где нужно было бы моделировать записи временного ряда как rows
не columns
. Этот тип использования часто называют "широкими строками".
- если вы посмотрите на Readme на Apache Cassandra git repo, он говорит, что
Cassandra-это секционированный магазин строк. Строки организованы в таблицы с необходимым первичным ключом.
секционирование означает, что Cassandra может распространять ваши данные несколько машин в приложении-прозрачная материя. Кассандра будет автоматически передел как машины добавляются и удаляются от группа.
Row store означает, что, как и реляционные базы данных, Cassandra организует данные по строкам и столбцам.
-
базы данных, ориентированные на столбцы или столбцы, хранятся на диске.
Эл.г: стол
Bonuses
таблицаID Last First Bonus 1 Doe John 8000 2 Smith Jane 4000 3 Beck Sam 1000
на построчным система управления базами данных, данные будут храниться следующим образом:
1,Doe,John,8000;2,Smith,Jane,4000;3,Beck,Sam,1000;
на система управления базами данных, данные будут храниться следующим образом:
1,2,3;Doe,Smith,Beck;John,Jane,Sam;8000,4000,1000;
Кассандра в основном магазине
- Cassandra сохранит вышеуказанные данные как,
"Bounses" : { row1 : { "ID":1, "Last":"Doe", "First":"John", "Bonus":8000}, row2 : { "ID":2, "Last":"Smith", "First":"Jane", "Bonus":4000} ... }
- читать этой для получения более подробной информации.
надеюсь, что это помогает.
вы оба хорошие моменты, и это может ввести в заблуждение. В Примере, где
apple -> colour weight price variety
"red" 100 40 "Cox"
apple является ключевым значением, а столбец-данными, которые содержат все 4 элемента данных. Из того, что было описано, похоже, что все 4 элемента данных хранятся вместе как один объект, а затем анализируются приложением, чтобы вытащить только требуемое значение. Поэтому с точки зрения IO мне нужно прочитать весь объект. IMHO это по своей сути строка (или объект), а не столбец.
хранение на основе столбцов стало популярным для складирования, потому что оно предлагает экстремальное сжатие и уменьшение ввода-вывода для полного сканирования таблиц (DW), но за счет увеличения ввода-вывода для OLTP, когда вам нужно вытащить каждый столбец (выберите *). Большинство запросов не нуждаются в каждом столбце, и из-за сжатия IO может быть значительно уменьшен для полного сканирования таблицы всего для нескольких столбцов. Позвольте привести пример
apple -> colour weight price variety
"red" 100 40 "Cox"
grape -> colour weight price variety
"red" 100 40 "Cox"
у нас есть два разных фруктов, но оба имеют цвет = красный. Если мы храните цвет в отдельной странице диска (блоке) от веса, цены и разнообразия, поэтому единственное, что хранится,-это цвет, затем, когда мы сжимаем страницу, мы можем достичь экстремального сжатия из-за большого дублирования. Вместо того, чтобы хранить 100 строк (гипотетически) на странице, мы можем хранить 10 000 цветов. Теперь, чтобы прочитать все с красным цветом, это может быть 1 IO вместо тысяч IO, что действительно хорошо для складирования и аналитики, но плохо для OLTP, если мне нужно обновить всю строку, так как строка может иметь сотни столбцов, а для одного обновления (или вставки) могут потребоваться сотни IO.
Если я не упускаю что-то, что я бы не назвал это столбчатым, я бы назвал это объектным. До сих пор не ясно, как объекты расположены на диске. Несколько объектов помещаются на одну и ту же страницу диска? Есть ли способ обеспечить, чтобы объекты с одинаковыми метаданными шли вместе? До того, что один плод может содержать разные данные, чем другой плод, так как его просто мета данные или xml или все, что вы хотите сохранить в самом объекте, есть ли способ гарантировать, что определенные соответствующие типы фруктов хранятся вместе для повышения эффективности?
Ларри
семейные колонке не означает колоночную. Cassandra-семейство столбцов, но не ориентированное на столбцы. Он хранит строку со всеми семействами столбцов вместе.
Hbase-это семейство столбцов, а также хранит семейства столбцов в колонковой ориентации. Различные семейства столбцов хранятся отдельно в узле или даже могут находиться в разных узлах.
самый однозначный термин, с которым я столкнулся, -широкий столбец store.
вид двумерный ключ-значение store, где вы используете Ключ строки и ключ столбца для доступа к данным.
основное различие между этой моделью и реляционными (как ориентированными на строки, так и на столбцы) заключается в том, что информация о столбце является частью данных.
Это означает, что данные могут быть редкие. Те средства разные строки не должны иметь одинаковые имена столбцов или количество столбцов. Это позволяет использовать полуструктурированные данные или таблицы без схем.
вы можете думать о широкодиапазонных хранилищах как о таблицах, которые могут содержать неограниченное количество столбцов и, следовательно, являются широкими.
вот несколько ссылок, чтобы поддержать это:
- в данной статье в MongoDB
- эта статья Datastax упоминает его тоже, хотя он классифицирует Кассандра как хранилище ключей.
- эта статья db-engines
- эта статья 2013
- Википедия