Close

29.04.2019

Выбор сегмента для «ADB» = «AcapellaDB»

Мини исследование (2 недели). Взгляд на сегменты пользователей баз данных и проблемы, с которыми они сталкиваются.

К сведению: AcapellaDB решает такие ключевые проблемы пользователей баз данных:

  1. автоматически получаем master-master репликацию, zero-config без каких-то усилий. Это доступность, это надежность;
  2. автоматически получаем авто-шардинг, это повышает вместимость кластера с сохранением целостности и без разрыва связности;
  3. большие по объёму ACID транзакции с которыми можно работать через соединения с разными узлами кластера;
  4. отсутствие точек отказа и моментов времени когда такие точки могут существовать.

Все это сильно упрощает разработку для…,  а в об этом ниже. Я далее рассмотрю типовые проблемы различных типов пользователей баз данных.

Пользователи бизнес решений автоматизации бизнеса, например, продуктов 1С.

1С это платформа, у которой может быть разная база данных в сетевой инсталляции. В самом простом виде они хранят данные в файлах или своей встроенной базе локально, но при росте масштабов переходят на трехзвенку  «клиент-сервер-база данных».

1С может работать с MS SQL или с Postgres. Обычно мощности этих баз хватает.

Проблемы есть, когда требуется поднять надежность. Пример: сервер отключился или там сбой.

  • аппаратная авария приводит к потере данных в 90% случаев
  • требуется настраивать и поддерживать бекапы, и восстанавливать из них при необходимости
  • дополнительные затраты на репикацию, которой нет из коробки и ее довольно сложно\дорого сделать. Не говоря уже о том, что не синхронная репликация для финансовых данных — плохое решение. Она не даёт целостности (при подмене сервера из-за своих задержек) и не масштабирует производительность (т.к. в 1С много операций записи)

Чаще всего решается «бескомпромиссно» — через бекапы.  Тут вторая проблема, она ооочень старая:  «разворачивания дампа\бекапа базы» т.к. 1С сам из своего формата это делает, занимая весь своп, т.е. просто тратит память в момент разворачивания дампа.

В итоге объём базы ограничивается реально объёмом своп файла 🙂

Надежность интересует людей, и да — данные теряются при креше базы.

Там все держится на рекомендациях самого 1С . Сказали «MS SQL сервер» — значит его ставим, сказали: «Postgres» — значит PG. Думать пользователи не станут, сравнивать тоже.

Industrial SQL

IndustrialSQL — построен на базе MS SQL Server. Маркетинг говорит: он лучше для промышленных целей, быстрее, надежнее, итд.

Используется и известен в АСУТП мире, например InTouch SCADA использует его. Почему он? Никто не может внятно объяснить. Это чистый маркетинг.

Но для скорости там отказались о ряда вещей по надежности, при аварии потеряется «чуть больше данных», но т.к. они записываются в него быстрее, чем обычно, во масштабах времени это потеря данных «не за много секунд». В этом сегменте (АСУТП) вообще работает скорее «картельный сговор», чем здравый рассудок.

No Comments, как говориться. лучше туда не соваться — там все закостенелое

Корпорации, которые разрабатывают software для себя — для своих продуктов

Их можно разделить на такие группы:

  1. с микросервисной архитектурой,
  2. монолитная архитектура

Кроме того, одним их них требуется целостность, а другие могут без нее жить.

Если целостность не обязательна, то

  • легче идти в сторону микросервисов и «резать базу».
  • возможно RDBMS с транзакциями вообще не нужна, например в делаете поисковые движки и тексты обрабатываете или работаете с «Machine Learning»

Корпорация с своим B2B\B2C продуктом для множества клиентов с не малыми нагрузками

Есть ли у них репликация ? Как они готовят PG, например?

У корпораций в целом, похоже, более наплевательское отношение к надежности и клиенту. Особенно это проявляется, при постоянном выходе новых версий. Отдел Q&A может повысить качество в целях конкуренции, но это делается не за счет архитектуры ПО, а за счет более четких процессов управления.

Они думают о экономии и ускорения развертывания, а не о качестве своих продуктов. Кто думает о качестве больше?

Данных в базах данных у них много, но это данные разных клиентов, их точно можно шардить и реплицировать тоже можно.

Пользователи (которые платят) раскиданы на схемы и на базы, они выбираются согласно client_id , у каждого свои данные. Это шардирование по признаку.

Довольно типовое решение. Подключение сразу идет к нужному узлу и нужной схеме.
У каждого клиента — своя база. Шардирование это не только увеличение capacity, это еще и изоляция, т.е. это нормально ложиться на потребности клиентов. (я бы даже сказал, что это изоляция в первую очередь)

Монолитный сервис часто, развиваясь, перестает быть монолитным и становится множеством сервисов и продуктов, связанных друг с другом. Это нормальный способ масштабировать каждый из «кусочков».

Одна из проблем связанных микросервисов  в «отношении к ошибкам».

Есть и такие микросервисы, которые должны работать с двумя базами, например, кого-то куда-то приглашать. Это делают сервисы, у которых своя база с пометками и доступ в другие базы. Такие микросервисы вроде бы должны выполнять сложную работу по обработке ошибок синхронизации и все корректно обрабатывать, но реально они это часто не делают. 80% кода работает без ошибок, а 20% это сложный код для обработки сложных ситуаций.

Часто отношение такое: Ну не создался какой-то документ, — он просто не будет отображен, ну нажмет пользователь еще раз кнопку — ничего страшного. Экономия на этих сложных 20% случаев, даёт 50% выигрыш в стоимости ПО и ускоряет выход на рынок.

Еще есть «проблемы с петлями».  

Начинается она так: перешли на микросервисы, базу разбивают на части — несколько баз данных.
далее очень скоро начинается борьба с «петлями». Это когда один микросервис вызывает второй микросервис, а тот через цепочку опять вызывает первый микросервис зачем-то.

Появляется очередь, она наполняется во всех сервисах цепочки, в итоге может даже кончится — привести к блокировке. Да и вообще это не камильфо, когда 2 и более сервисов нужно вызывать для одного веб-метода.

Дублирование колонок в разных сервисах — стандартное решение, делаем так, чтобы микросервисам данных хватало. В общем, не по-всякому можно базу порезать.

Кроме того, раз это разные разы, то тут возникает задача синхронизации данных, каждые данные (каждый столбец) где то имеет главное свое место хранения, а где-то он нужен для «устранения петель» и он туда  должен быть переброшен…

Кто должен об этом помнить? логично, что задачи повалятся в DBA, который просто триггеров напишет и настроит реплик, представляете какой ад получится, если таких столбцов и оптимизаций будет много, и что будет с корректностью и доступностью при авариях ?  Представляете как сложно будут потом схему данных поменять?

Тут также важно: если начато движение в сторону микросервисов, то как бы не нужна уже единая распределенная база, посмотрели на нее — интересно! Но пик кризиса миновал, теперь у ребят уже другие проблемы, другого типа и их решать гораздо более дорого.

Я считаю, что нужно доказывать необходимость использования NewSQL таким компаниям

Чтобы  не было петель нужно менять структуру сервисов — раз они появились — нужно общие данные выносить в отдельные сервисы. Это как раз правильно с логической точки зрения, не всегда это можно сделать с операционной точки зрения, но это не такая уж сильная проблема.

PS  В заключении я добавлю про этот тип компаний  и почему его нельзя списывать со счетов из-за микросервисной архитектуры.

Корпорации разрабатывающие и помогающие в эксплуатации software для государственных заказчиков

Виктор говорит: «работаем для банков, но мы отбрыкиваемся от интеграции разрабатываемых сервисов в их систему до последнего,  а то там всё заглохнет — слишком громоздкие бюрократические процедуры начинаются после интеграции, это тормозит сильно разработку…»

«Делаем веб-сервисы для Сбербанка, работая в их дочке. Используем PG и Mongo. Пишем «прикладнуху», о объёме данных пока не думаем, точнее их нам не называют пока, а гадать мы не должны.»

Вот пойдет интеграция и тестирование — будем всё в бою выяснять. Считается, что PG и особенно Mongo могут скейлится до требуемых пределов.

Когда пройдет интеграция для нашего сервиса, то у нас все будет сразу сложно. Мы видим по другим сервисам это сейчас.

Много согласований, интеграционные шлюзы, пользователи для API — все надо согласовывать. С безопасностью много заморочек. Стоит сервису войти в основной состав ПО Сбербанка — можно утонуть в море согласований, разработка встанет, поэтому мы стараемся отбрыкиваться от интеграции и пилим фичи сейчас, пока нас не включили. Пока мы можем менять и архитектуру и выбирать технологии, но потом уже это усложниться и мы не будем этого делать. Вон у ребят рядом уже такие требования: java6, IE, Centos старый, все зависимости надо билдить в свои пакеты, чтобы они разворачивались без интернета, никакого Docker там нет, конечно, и это еще мягко… все таки Linux можно скриптовать хоть как-то.

Коля и Витя работают в другой компании, заказчик — государство, мин.фин и регионы.

«Репликация у всех как-бы есть», но для нее по хорошему нужен большой сетевой канал и винты должны быть «разные». Это как бы очевидно, но не для всех 🙂

«Шардинг» он у всех примерно одинаковый. Но «шардинг» — это касается не только админов , но и программистов тоже.
По хорошему, нужно софтверное решение, которое даст гибкость в выборе критерия шардинга.

Бывает и такая схема: ключ шардинга …далее  пять таблиц через связи … далее таблица большая, которую и нужно разбивать, где «большая таблица» растет на 300 ГБайт в год на клиента, у старых клиентов это уже 2-3 ТБайта.

а Проблема в основном не с размерами, а с выборками.

Бекапы, это отдельная задача, часто они «по-клиентские».

Если все данные принадлежат клиенту, то классический шардинг решает это, но для нас важнее сами таблицы бить, чтобы с ними легче было работать, обслуживать.

Иногда, чтобы его сделать, проще нарушить 3-ю нормальную форму…, ну и что?… первый раз, что-ли?

Витя: консистентность, распределенность, надежность… это хорошо, но проблемы у нас другие.
Мы делаем  софт для гос. структур. 5000-10000 юзеров на инстяляцию сервиса.

Несколько продуктов \ до десяти. Инсталляция каждого продукта делается от 10-100 раз на оборудовании заказчика, что важно!
Оборудование не всегда дают в требуемом объёме, это чаще одна большая машина чем две.
Если она ляжет — пользователи подождут. Не согласны ? — давайте вторую машину. Сами решат, в общем, они уже большие дяди, ждать или давать больше машин.
Нагрузка не очень большая, объём довольно большой. Нагрузка на базу 20% всего в пике.

Базы у нас Oracle и Postgres, от Oracle отказываются все сейчас, хоть он и закуплен давно.
Продукт — «условно монолит», т.е. некоторые вещи выделены в отдельные сервисы, но микросервисной архитектуру не назовешь. \ в отличии от компаний с миллионами пользователей.

Одна из проблем «нужно следить за размером базы»:

Есть большие разреженные таблицы и большие по объёму изменений транзакции в которых меняется много значений. Это значит, что все фрагментируется на диске и PG пишет в новые страницы, а чтобы старые страницы стали доступны снова их нужно «собрать».

В PG есть команда Vacuum. Она не работает с «потроганными»  данными, если её делать на больших таблицах, то в период сбора таблица может очень сильно вырасти. Есть Vacuum Full который крайне полезен, но он пишет все в новый файл когда делает дефрагментацию, и требуемый объём диска удваивается.

Поскольку диск и так дан без запаса заказчиком — полный вакуум не сделать.

Переход на «PG с шардингом» \ с партиционированием дает то, что таблицы становятся меньше и сборка всё еще требует двукратного роста места, но для меньших таблиц это совсем другое дело — уже можно пользоваться и жить.

Бить таблицы по кускам — хорошая идея. Кроме того backup restore сильно быстрее работает, рост скорости по числу ядер, примерно.
Есть правда одно ограничение: не может быть FK на разбиваемую таблицу, иногда это проблема, но нас, к счастью, она не каснулась.

Интересно: От Oracle отказались по нескольким причинам. Главная: импортозамещение, от него в гос структурах избавляются. Экономия ? нам она не понятна — мы её не можем оценить, мы же не покупаем лицензии, а они не покупают лицензию  на сервер — а покупают сразу на дата-центр, там другие расценки.

С точки зрения разработчика у Oracle дурацкие недостатки (смеются:)

  1. дурацкие ограничения на имена таблиц 21 символ, вроде. Точнее его как бы нет, этого ограничения, но символы далее этого предела не учитываются в имени как уникальные при сравнении, поэтому часто он ошибками о не уникальности может сыпать
  2. ограничения на длину имени внешнего ключа, около 120 символов. Там тоже бред: это имя складывается всегда как имя таблицы + поле + имя таблицы «куда» + имя индекса и если взять максимум по именам , то не хватает даже … т.е. таблицы приходится называть даже короче, чем это разрешено.
  3. ооочень медленно читаются метаданные. Пример: для 200 примерно таблиц (а это не очень и много) может вычитка занимать минуту! Витя даже целое исследование замутил почему так, выяснил такое: в Oracle статистика по таблицам считается в методе получения метаданных 8) Зачем они так сделали ? — не ясно, legacy, наверное, опять.

Новость (я не слышал ее): Сбербанк отказался от grid вычислителя \ GridGain, а это так. Грид захлебнулся в их вычислительном объёме, он порождал новые и новые узлы, а от этого все больше и больше захлебывался.

Коля: Для основного их конвейера нужно что-то очень быстрое, а микросервисы хороши сбоку, для каких-то  не основных или дополнительных задач.

Мнение

Я: я думаю, что Коля прав, что не верит в микросервисы как в «супер решение», что дает им дополнительные функции, мне кажется, что разрезание базы и нарушение форм это пагубная практика, которая порождает проблемы (я, видимо, идеалист)

Нужно решать проблему — скейлить хранилище, а не уходить в нарушение «проекта схемы данных», обходя ее.  Это полумера, т.к. она порождает проблемы, то можно согласиться получить не большое их количество, но если это «центральное решение партии» и все на микросервисах, то это приводит к большой путанице и сложности анализа по надежности.

Аналитика: тоже проблема. Колоночное решение у ПГ вроде есть, но многие выбирают сразу ClickHouse. Наверное это проще?  @ОлегГуров, напиши в чем тут дело.

Обычно нужно делать что-то типа предсказаний и рекомендаций. Есть витрина, есть история и данные. Загоняется все в куб и агрегируется. Проблемой это становится когда надо видеть агрегат в реальном времени.
Эти базы заточены на быструю работу с диапазонами и вычисления, подсчеты.

В общем, а таких базах все трейдоффы направлены как-то не так , как у баз для операций и хранения, а, как бы, «перпендикулярно».
Мы используем ClickHouse, он быстрый для агрегатов, заточен на выборку диапазонов и операции с ними, и живем пока.

А вот у «Минфина» эта проблема номер 1.

Витя: «У них конские объёмы данных, я даже бы сказал ‘конские в кубе объемы'».  🙂

 

Аутсорсинговые компании, разрабатывающие software для разных заказчиков — легче относятся к eventual consistency

Компания делает для заказчика решение и сдаёт ему. Иногда заказчик не имеет своего DBA.

Если  им сдать решение с репликацией и кластером с ручным управлением скейлом, и впридачу дать инструкцию, что, мол,  если будут проблемы, то вот инструкция из 100 шагов и траблшотинг… не каждый заказчик это примет.

Заказчик хочет zero-config решение, всегда. Даже если команда умеет готовить OpenSource базы или платные базы в настроенные решения, то они не пойдут на конфигурации даже средней сложности. Будут их избегать.

Распределенное автономное решение им нравится. 

NoSQL нравится потому, что позволяет проще скейлится

Андрей однажды ушел из компании потому, что они не думали о масштабировании совсем. Он сказал: «ну ребята…, у вас все загнется, давайте я лучше сразу пойду… пока».

Говорит разработчик: Распределенность — признак всего в новом мире. Репликация … ну в текущем проекте мы ее не используем явно, но она есть в Cassandra, на которую мы перешли. Настраивать её там предельно просто, по сравнению с rdbms, в которой нужен DBA, чтобы ее обслуживать, а мы делаем решения на заказ.

Репликация это боль. Какая ?
1. ей надо еще уметь воспользоваться, запись ей не скейлится, а только чтение и то, если смог правильно всё сделать
2. её надо настроить , развернуть. Кто это будет делать? Даже если у нас эти спецы есть, а есть ли они у клиента? Надо чтобы было проще. Нужен  zero config

Если у заказчика есть DBA, то можно рассматривать репликацию, если его нет — «проще взять распределенное решение». «Была бы у нас команда побольше, но и то вряд-ли мы заморочились бы с репликацией, вот как её у клиента поддерживать?».

NoSQL Cassandra у нас используется как key-value. Полный пейджинг по ней не сделать, если Вам хватит Next, Next — то вариант, наш вариант.
NoSQL тоже есть персистентные и в памяти для ситуаций, когда наплевать на потерю данных.

Нужно «распределенное решение» — нода работает «с близкими данными». Мы еще не пробовали транзакции Casssandra’s, но попробуем (Я: ну удачи :)… и правда удачи, раз она им подходит). Работаем на Java, у касандры для java есть нативное решение.
Наше решение это query в касандру, а запись через конвейер в kafka и обработку событий.

Илья. Работает с текстами, анализом текстов.

Они делают ядро платформы для анализа текстов. У них нет проблемы в целом с согласованностью и целостностью. Согласованность «в конечном счете» их устраивает. Dataflow у них специфический, начинается с пауков и анализов и заканчивается выгрузкой результатов анализа в базу данных. В таком подходе можно реплицировать довольно не требовательным образом, шардировать и в конечном счете получать почти линейную масштабируемость.
Поэтому NewSQL для них не сильно актуален.

Все кладется на алтарь скорости ответа юзеру, нужно складывать в базу так, чтобы по готовым базам собрать и посчитать ответ.

Они продают конечные решения для массовых потребителей (типовые решения, для класса потребителей), а не только ядро, т.е. покупатели не люди использующие библиотеки поиска, а компании которым требуется какой-то (типовой) анализ с помощью данных технологий, этот анализ часто допускает многократную продажу, т.е. имеются целые сегменты покупателей конечных решений.

Антон — директор аутсорсинговой компании

Компания не большая (15 чел), работает на заказ для корпоративных и гос клиентов, стек на java.
Вот компания, казалось бы — наш клиент, но нет.  Они обходятся стандартными базами и проблем пока не имеют. 

Они хотят повышать свои возможности в глазах заказчика, имея больше «scale» компетенций и поставляя, more robust решения.

Используют MySQL, ElasticSearch, Mongo. (опять NoSQL)

Есть большие проекты с документооборотом и нагрузками, но не много и не часто.

Но! чаще всего им хватает обычных решений, т.е. они скейлят MySQL и Mongo а если будут проблемы, то у заказчика, но пока не было.

 

Разработчики мобильных приложений (внезапно)

Сегодня, часто MobileDev используют двухзвенную архитектуру (надеюсь как не основную базу).

Поток заказов на mobile таков, что они не всегда заказывают сервисный бекенд, есть задачи для которых используются БД вроде Firebase.

Основные фичи, которые им нужны:

  • push notifications
  • некоторые движки индексации используют Firebase как хранилище

Однако бывает, что вся логика приложения размещена в приложении, а данные в облачной БД, бекенд — сервис сильно урезан.

Олег: Это вариант — только для прототипов приложений. Ведь менять схему и обновлять приложение в этом случае никак

Интересует в первую очередь потому, что может работать offline. Данные лежат на мобильнике и синхронизируются с Firebase. Ни о каких консистентностях тут нельзя мечтать, но они мечтают хотя бы о SQL.  Эту фичу мы им сможем дать, но не все другие.

Заключение

Менталитет у западного клиента отличается, и тут нужно исследовать дальше, но технический уровень решений в России и там не сильно отличается. Мне думается с технической стороны сегментирование и проблемы похожи.

Я: Гос заказчика и конторы которые на них работают с их бюрократией и требованиями я считаю большим риском.

У них не много нагрузки и проблема надежности не так актуальна.  Обычно им хватает монолитных решений и одной машины.  У больших  гос исполнителей, типа ЛАНИТ, точно есть сервисы в которых у них к ADB будет интерес, но как им продать? и велик ли этот сегмент? — очевидно, что не велик.

SaaS издатели, создающие ПО для использования  в своих дата центрах

Изначально я их делил на тех у кого «микросервисная архитектура» и у кого «фаза активного роста, но они еще не перешли на микросервисы».  Я считал, что те, кто перешли на «микросервисы» те снизили потребность в большой монолитной базе и это рассматривалось как риск.

Я ошибался.

Поговорив с Вадимом — «главным админом», руководителем дата центра большой ИТ компании, .. далее прочие регалии,  я осознал одну важную мысль.

Желание разбить базу и решение на микросервисы не связано с потребностью в NewSQL

Действительно: микросервисы это модульность и гибкость, это логическое выделение отдельных звеньев системы в свои зоны ответственности, это метод масштабирования логики и повышения надежности. В итоге появляется несколько сервисов, бывает так, что не «микро», а очень больших сервисов.

Появляется, скажем, сервис логически отделенный, но далее не делимый, какой-то очень важный и нагруженный, и его надо масштабировать — разместить на нескольких машинах. Это неизбежная ситуация.  Этому «макро сервису»по прежнему нужна: надежность, доступность, своя надежная ОДНА база данных, разнесенная на несколько машин.  — Это идеальная ситуация, когда есть потребность в NewSQL

Конечно не все организации с этим сталкиваются, не все выберут наше решение, но это типовая ситуация и тест очень прост:

— «Мы предлагаем попробовать, смотрим что использует их сервис, если можем — показываем как работает их сервис на нашей базе или понимаем почему он  не может работать (например хранимки). Далее диалог, или их устраивает или нет.» Это довольно простой тест т.е. этот вопрос с большой организацией  решается за месяц, а не год.

Решение у нас совместимое с PG поэтому если используется базовый функционал , то эта проверка занимает мало времени.

Так что пока их со счетов не списываю. Надо признать, что сам так по Европам не наездишься… Вот если бы сделать это пару раз и описать для таких компаний подробный туториал, чтобы они сами могли такой тест пройти…

ИТ Компании,  разработчики ПО, которые делают ПО на заказ

Самый оптимальный , на мой взгляд сегмент.  Действительно многие точки зрения на разработку и требования к Базам данных у нас с ними совпадают:

  • ищут решение, которое увеличит их возможности
  • не занимаются поддержкой, как основной деятельностью, поэтому предлагают решения, которые не требуют сложной поддержки
  • они легко экспериментируют
  • они готовы смешивать NoSQL  , NewSQL, RDBMS, …
  • SQL увеличивает производительность команды разработки, поэтому NewSQL для них более предпочтителен
  • они переходят на NoSQL из — за : легкость расширения кластера (devops) , горизонтальное масштабирование
  • от целостности  отказываются, потому что готовы, а не потому что так требуется.

Все это ведет к такому правильному способу разработки для них с ADB

  1. пишут решение с использованием ADB, ханя в БД только данные
  2. периодически меряют latency
  3. Если в итоге latency их устраивает — продают заказчику решение с лицензией ADB, объясняя, почему оно лучше, если он отказывается от ADB — то получает Postgres
  4. Если latency не устраивает, то переходят на Postgres ничего не замечая.

Они могут рассматривать ADB как источник дополнительного дохода.

 

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *