Коли НЕ використовувати Cassandra?

Останнім часом було багато розмов про Кассандру .

Twitter, Digg, Facebook та ін.

Коли має сенс:

• використовувати Кассандру,
• не використовувати Cassandra, і
• використовуйте RDMS замість Cassandra.

Немає нічого подібного до срібної кулі, все побудовано для вирішення конкретних проблем і має свої плюси і мінуси. Ви самі вирішуєте, яке у вас виникнення проблеми та яке найкраще рішення для цієї проблеми.

Я спробую відповісти на ваші запитання по одному в тому ж порядку, в якому ви їх задали. Оскільки Cassandra базується на базі даних NoSQL, важливо зрозуміти, навіщо використовувати базу даних NoSQL, перш ніж я відповім на ваші запитання.

Навіщо використовувати NoSQL

Що стосується RDBMS, зробити вибір досить просто, оскільки всі бази даних, такі як MySQL, Oracle, MS SQL, PostgreSQL цієї категорії, пропонують майже однаковий вид рішень, орієнтованих на властивості ACID. Що стосується NoSQL, рішення стає складним, оскільки кожна база даних NoSQL пропонує різні рішення, і ви повинні зрозуміти, який з них найкраще підходить для ваших програм / системних вимог. Наприклад, MongoDB підходить для випадків використання, коли ваша система вимагає зберігання документів без схем. HBase може бути придатним для пошукових систем, аналізу даних журналу, або будь-якого місця, де сканування величезних, двовимірних таблиць без приєднання є потребою. Redis створений для забезпечення In-Memory пошуку таких різновидів структур даних, як дерева, черги, пов’язані списки тощо, і може бути гарною придатністю для створення лідерів у режимі реального часу, типів паб-підсистеми. Так само є інші бази даних у цій категорії (включаючи Кассандру), які підходять для різних заяв про проблеми. Тепер давайте перейдемо до оригінальних запитань і відповімо на них по черзі.

Коли використовувати Кассандру

Будучи частиною сім'ї NoSQL, Cassandra пропонує рішення проблем, коли однією з ваших вимог є наявність дуже важкої системи запису, і ви хочете мати досить чуйну систему звітування поверх цих збережених даних. Розглянемо випадок використання веб-аналітики, де дані журналу зберігаються для кожного запиту, і ви хочете створити навколо нього аналітичну платформу для обліку звернень за годину, браузером, IP-адресою тощо в режимі реального часу. Ви можете посилатися на цю публікацію в блозі, щоб дізнатися більше про випадки використання, у які підходить Кассандра.

Коли використовувати RDMS замість Cassandra

Кассандра базується на базі даних NoSQL і не забезпечує властивостей ACID та реляційних даних. Якщо у вас є вимоги до властивостей ACID (наприклад, фінансові дані), Кассандра не буде придатною для цього випадку. Очевидно, ви можете зробити це для вирішення, однак ви в кінцевому підсумку будете писати багато коду програми для імітації властивостей ACID і втратите час на ринок. Також управління такою системою з Кассандрою було б для вас складним і стомлюючим.

Коли не використовувати Кассандру

Я не думаю, що на це потрібно відповідати, якщо вищезгадане пояснення має сенс.

Оцінюючи розподілені системи даних, ви повинні врахувати теорему CAP - ви можете вибрати дві з наступних: послідовність, доступність та допуск розділів.

Кассандра є доступною системою, стійкою до перегородки, яка підтримує можливу послідовність. Для отримання додаткової інформації дивіться цю публікацію в блозі, яку я написав: Візуальний посібник по системам NoSQL .

Кассандра - це відповідь на певну проблему: що ви робите, коли у вас є стільки даних, що вони не вміщуються на одному сервері? Як ви зберігаєте всі свої дані на багатьох серверах і не порушуєте свій банківський рахунок і не робите своїх розробників божевільними? Facebook отримує 4 терабайта нових стислих даних КОЖЕН ДЕНЬ. І ця кількість, швидше за все, зросте більше ніж удвічі протягом року.

Якщо у вас немає такої кількості даних або якщо у вас є мільйони, щоб заплатити за встановлення кластера Enterprise Oracle / DB2 та фахівців, необхідних для їх налаштування та обслуговування, то вам все добре з базою даних SQL.

Однак Facebook більше не використовує кассандру і тепер використовує MySQL майже виключно для переміщення розділів в стеку додатків для більш швидкої роботи та кращого контролю.

Загальна ідея NoSQL полягає в тому, що вам слід скористатись тим, що сховище даних найкраще підходить для вашої програми. Якщо у вас є таблиця фінансових даних, використовуйте SQL. Якщо у вас є об'єкти, для яких потрібні складні / повільні запити для відображення реляційної схеми, використовуйте об'єкт або сховище ключа / значення.

Звичайно, майже будь-яка реальна проблема, з якою ви стикаєтесь, знаходиться десь між цими двома крайнощами, і жодне рішення не буде ідеальним. Вам потрібно врахувати можливості кожного магазину та наслідки використання одного над іншим, що буде дуже специфічно для проблеми, яку ви намагаєтеся вирішити.

Окрім наведених вище відповідей про те, коли користуватися Касандрою, а коли не користуватися Кассандрою, якщо ви все-таки вирішите використовувати Кассандру, ви можете подумати про те, щоб не використовувати саму Кассандру, а одного з її багатьох родичів там.

Деякі відповіді вище вже вказували на різні системи "NoSQL", які мають багато властивостей з Кассандрою, з деякими невеликими або великими відмінностями, і можуть бути кращими за саму Кассандру для ваших конкретних потреб.

Крім того, нещодавно (через кілька років після цього запитання було спочатку задано питання ) був випущений клон Кассандри під назвою Сцилла (див. Https://en.wikipedia.org/wiki/Scylla_(database) . Scylla - це повторна реалізація Cassandra з відкритим кодом у C ++, яка стверджує, що має значно більшу пропускну спроможність та менші затримки, ніж оригінальна Java Cassandra, при цьому в основному сумісна з нею (у функціях, API та форматах файлів). Тож якщо ви вже розглядаєте Кассандру, ви можете також розглянути Сциллу.

Розмовляючи з кимось посеред розгортання Кассандри, це не справляється з багатьма багатьма. Вони роблять хакерську роботу, щоб зробити своє початкове тестування. Я говорив з консультантом Кассандри з цього приводу, і він сказав, що не рекомендуватиме його, якщо у вас буде встановлена ​​ця проблема.

Вам слід задати собі такі питання:

1. (Гучність, Швидкість) Чи будете ви записувати та читати TONS інформації, стільки інформації, що жоден комп'ютер не міг би обробляти записи.
2. (Глобальне) Чи потрібна вам ця можливість письма та читання у всьому світі, щоб записи в одній частині світу були доступні в іншій частині світу?
3. (Надійність) Вам потрібна ця база даних, щоб постійно працювати і працювати, і ніколи не виходити з ладу, незалежно від того, яка Хмара, яка країна, чи це VM, контейнер або голий метал?
4. (Можливість масштабування) Чи потрібна вам ця база даних, щоб мати можливість продовжувати легко розвиватися та масштабуватися лінійно
5. (Послідовність) Вам потрібна послідовність TUNABLE там, де деякі записи можуть відбуватися асинхронно там, де інші повинні бути сертифіковані?
6. (Навичка) Чи готові ви зробити все, що потрібно для вивчення цієї технології та моделювання даних, що стосується створення глобально розподіленої бази даних, яка може бути швидкою для всіх, у будь-якому місці?

Якщо для будь-якого з цих питань ви думали "можливо" чи "ні", вам слід скористатися чимось іншим. Якщо у вас було "пекло так" як відповідь на всі вони, то вам слід скористатися Кассандрою.

Використовуйте RDBMS, коли ви можете робити все в одному ящику. Це, мабуть, простіше, ніж більшість, і кожен може з цим працювати.

Важливий один запит порівняно з газільйонним навантаженням легкого запиту - це ще один момент, який слід врахувати, крім інших відповідей тут. По суті важче автоматично оптимізувати один запит у БД стилю NoSql. Я використовував MongoDB і стикався з проблемами продуктивності, намагаючись обчислити складний запит. Я ще не використовував Кассандру, але, мабуть, матиме те саме питання.

З іншого боку, якщо очікується, що ваше навантаження буде дуже великою кількістю невеликих запитів, і ви хочете легко розширити масштаб, ви можете скористатися можливою послідовністю, яку пропонує більшість баз даних NoSql. Зауважте, що можлива узгодженість насправді не є особливістю нереляційної моделі даних, але її набагато простіше реалізувати та налаштувати в системі на основі NoSql.

Для одного, дуже важкого запиту, будь-який сучасний двигун RDBMS може зробити гідну роботу, паралелізуючи частини запиту і скористатися стільки процесора та пам'яті, які ви кидаєте на нього (на одній машині). У базах даних NoSql немає достатньої інформації про структуру даних, щоб можна було робити припущення, які дозволять по-справжньому розумну паралелізацію великого запиту. Вони дозволяють легко масштабувати більше серверів (або ядер), але як тільки запит досягає рівня складності, ви, в основному, змушені розділяти його вручну на частини, з якими двигун NoSql знає, як з розумом поводитися.

З мого досвіду роботи з MongoDB, врешті-решт через складність запиту Монго не міг зробити, щоб оптимізувати його та запустити його частини на декілька даних. Mongo паралелізує кілька запитів, але не дуже добре оптимізує один.

Давайте прочитаємо кілька реальних справ:

http://planetcassandra.org/apache-cassandra-use-cases/

У цій статті: http://planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra

Вони роз'яснили причину, чому вони не обрали MySql, тому що синхронізація db занадто повільна.

(Також через 2-фразові фіксування, FK, PK)

Кассандра базується на папері Amazon Dynamo

Особливості:

Стабільність

Висока доступність

Резервне копіювання працює добре

Читати і писати краще, ніж HBase, (клон BigTable у Java).

wiki http://en.wikipedia.org/wiki/Apache_Cassandra

Їх висновок :

We looked at HBase, Dynamo, Mongo and Cassandra. 

Cassandra was simply the best storage solution for the majority of our data.

Станом на 2018 рік,

Я б рекомендував використовувати ScyllaDB для заміни класичної кассандри, якщо вам потрібна підтримка спини.

Плагін Postgres kv також швидший, ніж кассандра. Як ніколи не буде багатошарової масштабованості.

Я зупинюсь тут на деяких важливих аспектах, які можуть допомогти вам вирішити, чи дійсно вам потрібна Кассандра. Список не є вичерпним, лише деякі моменти, які я маю на увазі,

• Не вважайте Кассандру першим вибором, коли у вас є суворі вимоги щодо відносин (у вашому наборі даних).

• Кассандра за замовчуванням - це система AP (CAP). Але він підтримує налаштовану консистенцію, що означає, що він може бути налаштований на підтримку як CP. Тому не ігноруйте це лише тому, що ви десь прочитали, що це AP та шукаєте системи CP. Кассандру більш точно називають "налаштованою послідовністю", що означає, що вона дозволяє легко визначити необхідний рівень консистенції, балансуючи з рівнем доступності.

• Не використовуйте Кассандру, якщо ваш масштаб не великий або якщо ви можете мати справу з нерозподіленою БД.

• Подумайте важче, якщо ваша команда думає, що всі ваші проблеми будуть вирішені, якщо ви використовуєте розподілені БД, як-от Cassandra. Почати з цих БД дуже просто, оскільки він поставляється з багатьма типовими настройками, але оптимізація та освоєння її для вирішення конкретної проблеми потребує значної (якщо не багато) інженерної роботи.

• Кассандра орієнтована на стовпці, але в той же час кожен рядок також має унікальний ключ. Тож може бути корисним уявити про це як про індексований, орієнтований на рядки магазин. Ви навіть можете використовувати його як сховище документів.

• Кассандра не змушує вас заздалегідь визначати поля. Отже, якщо ви перебуваєте в режимі запуску або ваші функції розвиваються (як у спритному) - Кассандра сприймає це. Так що краще, спочатку подумайте про запити, а потім подумайте про дані, щоб відповісти на них.

• Кассандра оптимізована для дійсно високої пропускної здатності на запис. Якщо ваш випадок використання важкий для читання (наприклад, кеш), то Кассандра може бути не ідеальним вибором.

Інша ситуація, яка полегшує вибір - це те, коли ви хочете використовувати сукупну функцію, як сума, min, max, etcetera та складні запити (як у фінансовій системі, згаданій вище), тоді реляційна база даних, ймовірно, зручніша, ніж база даних nosql, оскільки обидва є неможливо на носі даних dataqse, якщо ви не використовуєте дійсно багато інвертованих індексів. Коли ви використовуєте nosql, вам доведеться робити сукупні функції в коді або зберігати їх окремо у власній колонці сім'ї, але це робить все досить складним і знижує продуктивність, яку ви отримали, використовуючи nosql.

Якщо вам потрібна цілком послідовна база даних із семантикою SQL, Cassandra НЕ є рішенням для вас. Cassandra підтримує пошук ключових значень. Він не підтримує SQL запити. Дані в Кассандрі "з часом узгоджуються". Одночасні пошуки даних можуть бути непослідовними, але з часом пошуки послідовні.

Якщо вам потрібна сувора семантика і вам потрібна підтримка SQL-запитів, виберіть інше рішення, наприклад MySQL, PostGres або комбінуйте використання Cassandra з Solr.

Кассандра - хороший вибір, якщо:

1. Вам не потрібні властивості ACID у вашому БД.

2. Було б величезна і величезна кількість записів у БД.

3. Існує вимога інтегруватися з Big Data, Hadoop, Hive та Spark.

4. Потрібна аналітика даних у реальному часі та покоління звітів.

5. Існує вимога вражаючого механізму відмови.

6. Існує вимога до однорідної системи.

7. Для налаштування існує велика кількість налаштувань.

Mongodb має дуже потужні сукупні функції та виразні сукупні рамки. Він має багато функцій, які розробники звикли використовувати із світу реляційних баз даних. Наприклад, структура даних / структура зберігання даних дозволяє використовувати більш складні моделі даних, ніж Кассандра, наприклад.

Все це, звичайно, пов'язано з компромісами. Отже, вибираючи свою базу даних (NoSQL, NewSQL або RDBMS), подивіться, яку проблему ви намагаєтеся вирішити та на ваші потреби в масштабованості. Жодна база даних не робить це все.

За даними DataStax, Кассандра - не найкращий випадок використання, коли є потреба

1- Апаратні пристрої високого класу. 2- сумісні з кислотними кислотами без відкоту (банківська транзакція)

• Він не підтримує повне управління транзакціями в таблицях.
• Вторинний індекс не підтримується.
• Доводиться покладатись на Elastic search / Solr for Secondary index, а спеціальний компонент синхронізації повинен бути записаний.
• Не сумісна з кислотою система.
• Підтримка запитів обмежена.

Apache cassandra - це розподілена база даних для управління великою кількістю структурованих даних на багатьох товарних серверах, забезпечуючи при цьому високодоступний сервіс і жодної точки відмови.

Архітектура ґрунтується виключно на теоремі про обмеження, яка є доступністю та толерантністю до розділів, і що цікаво, можливо, послідовно.

Не використовуйте його, якщо ви не зберігаєте обсяги даних у стелажах кластерів, Не використовуйте, якщо ви не зберігаєте дані часових рядів, Не використовуйте, якщо ви не патируєте свої сервери, Не використовуйте, якщо вам потрібна чітка послідовність.