Перехід з SQL на NoSQL: досвід проекту СМЕВ 2.0

В останні роки NoSQL і BigData стали дуже популярними в ІТ-індустрії, і на базі NoSQL успішно реалізовані тисячі проектів. Часто на різних конференціях і форумах слухачі задають питання про те, як модернізувати або перенести старі системи (legacy) в NoSQL. На щастя, у нас був досвід переходу з SQL на NoSQL у великому проекті СМЕВ 2.0, про яке я розповім під катом.


У 2011 році в одному з флагманських проектів Електронного уряду РФ ми зіткнулися з проблемою проектування централізованої системи логування (протоколювання). ЦСЛ – це логування для обробки прикладних і системних подій) в єдиному сховищі. Прикладні логи з сервера-додатка (звернення громадян до сервісу через портал держпослуг), лог балансування навантаження і шина інтеграції протоколюють логи через лог сервера, потрапляють в сховище, після цього дані індексується і агрегуються для звітності. Для формування звітності ми використовували систему BI. Нижче — концептуальна архітектура ЦСЛ:


Ситуація ускладнюється, коли беруть участь різні legacy гетерогенні системи зі своїм сховищем і системою логування. Одна з таких систем — СМЕВ (Система міжвідомчого електронного взаємодії, архітектура 2011 р.). Вона містить два типи шин інтеграції Oracle: WSM і Oracle OSB. Oracle WSM завжди протоколює повідомлення у вигляді BLOB у власній схемі БД. Також OSB логирует повідомлення в своїй схемі, а в інших ЗА свій підхід до логированию. Тепер уявіть, що вся ця система встановлюється в декількох регіонах РФ. Дані реплікується з інших Цодів у федеральний ЦОД для обробки та агрегації. Після консолідації та агрегації результуючі дані потрапляють в звіти через систему BI. В ілюстрації нижче наведена високорівнева архітектура СМЕВ 2.0:



У цієї системи був ряд недоліків:

  1. Погана масштабованість: першою проблемою стала динаміка зростання реєстрацій та використання сервісів у всіх органах влади. На початку 2011 року було зареєстровано всього 4 000 сервісів, а вже у другому кварталі 2013 року – понад 10 000. У кожному Цоді було зареєстровано приблизно по 1 000 soap-сервісів в шині інтеграції, а у федеральному Цоді — близько 2 000 сервісів. Таким чином, потреба в сервісі зросла майже в 6 разів: на федеральному рівні кількість логів сягала 21 млн в день, а по всій Росії – приблизно 41 млн записів, в годину-пік RPS (Request per second) — 1375. Звичайно, в порівнянні з високою навантажувальною системою це крихітні цифри. Весь процес обробки даних і звітності реалізований на основі PL/SQL, тобто обробка повідомлення і консолідація даних були реалізовані на PL/SQL, яка не була досить продуктивною. Після великого апдейта ми могли розібрати 450 тисяч повідомлень за 110 хвилин, коли нам на вхід надходило кілька мільйонів повідомлень в день.

  2. Другий сильно вплинув фактор – це реплікація даних між ЦОД, яка проводилася через різні гетерогенні інструменти: WHB, Oracle Goldengate, Oracle Stream. Якщо канал зв'язку з якихось причин відсутній, їх доводилося запускати повторно, щоб уникнути помилок.

  3. Масштабування Oracle RAC: також при збільшенні зростання потреби в сервісі, необхідно було масштабувати БД, що було дуже дорого і складно.

  4. Дорогі ліцензії З Oracle.
Всі ці причини спонукали нас переглянути нашу архітектуру і перейти на NoSQL. Після небільшого обговорення та порівняльного аналізу ми вирішили використати сховище Cassandra. Її плюси були очевидними:

  • Автоматична реплікація даних між датацентрами;
  • Шардінг даних «з коробки»;
  • Лінійне масштабування кластера Cassandra;
  • Відсутність єдиної точки відмови;
  • модель даних на основі Google Big Table;
  • СПО (open source).
В результаті у нас вийшло наступна концептуальна архітектура на базі Cassandra:


Кожен лог-сервер регіону або ЦоД пише протоколи у своєму вузлі кластера Cassandra. Дані автоматично реплікуються в аналітичному центрі для аналізу. Після аналізу та обробки даних в Hadoop Map Reduce дані вивантажуються через SQL loader для звітності в Oracle. Якщо з якихось причин канал зв'язку між аналітичними центрами та ЦоД відсутня, дані накопичуються (Hinted hands of) у кожному операційному сайті Cassandra і при появі зв'язку, дані з ЦоД потрапляють в аналітичні вузли.

Стек
  • Cassandra 1.1.5
  • Hadoop 1.0.3
  • Apache pig 0.1.11
  • Азкабану
Модель даних і їх обробки
Модель даних — Column Family, що складається зі стовпців і значень. Всі стовпці (column) статичні, тому що Pig не вмів працювати з динамічними стовпцями: таким чином, у нас зберігається корисне навантаження soap payload в стовпці. Через Hadoop Map Reduce проводиться розбір повідомлення, і результат зберігається в таблиці Cassandra для побудови агрегату. Після цього в результуючих метаданих запускається Reduce для побудови різних агрегатів. Агреговані дані експортується через Oracle SQL Loader з Hadoop HDFS в Oracle DB.

Продуктивність
Після налаштування (fine tuning) Hadoop ми отримали такі продуктивності. Розбір 300 млн рядків з Cassandra займає близько 100 хвилин. Побудова агрегату на 300 млн записів займає в середньому 170 хв. Pig скрипт агрегату даних у нашому випадку містить 3 великих операторів join, тому з'являється ще 3 тимчасових map.





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

Посилання:
  1. Система міжвідомчого електронного взаємодії
  2. MapReduce


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.