avlasov (avlasov) wrote,
avlasov
avlasov

Categories:

Прозрачный персистенс и OODBMS, а также более общий контекст подхода

Похожесть на NoSQL навело меня на мысль, а нет ли "прозрачного" персистенса у какого-нить OODBMS. В принципе db4o чем-то напоминает, правда у него есть всякие проблемки, которые делают его не очень интересным.

Собсно, на мой взгляд прозрачный персистенс - это не есть База Данных в любом виде. Когда мы пишем код на Жабе или на Скале, мы там не делаем селекты. Хотя конечно обходим коллекции. Вот и такая же идея стоит за прозрачным персистенсом - работаем как обычно с обычными объектами и коллекциями. А прозрачный персистенс отслеживает изменения, при этом делает это в определенные моменты времени.

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

Сейчас в основном господствует Stateless идеология, т.е. перекладывание проблема на БД и кэши. В частности ее следствием является непрозрачный персистенс, т.е. необходимость все как-то пихать в БД/кэши.

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

При этом Stateful подход на порядки быстрее (т.е. существенно больше чем в 10 раз). Фактически Stateful подход делает тоже самое что и распределенные кэши, просто с более богатым функционалом и интерфейсом. Фактически, если дополнить его удобным персистенсом, то БД можно не сколько убрать, сколько избавиться от необходимости ее кластеризовать и масштабировать. По идее stateful компонент может быть привязан к своей собственной БД.

Общая идеология, в рамках которой это достижимо:
1 считаем что у нас есть акторы - компоненты, взаимодействующие через обмен сообщений (включая удаленный доступ)
2 каждый компонент обрабатывает сообщения в порядке поступления - FIFO
3 вместе это дает casual order для всех сообщений
4 соответственно, как следствие, мы можем восстанавливать консистентное состояние всей системы, при некоторых условиях:
- обработка событий детерминированна
- каждый компонент умеет делать снапшот состояния в нужный момент (между обработкой событий)
5 перед тем как сообщение становится видимым извне, инициируется координированный сброс инфы в персистентное хранилище гарантирующий восстановление консистетного состояния перед отправкой сообщения
6 для оптимизации, может логаться не сам снапшот, а инкременты, либо в виде сообщений, нужных для восстановления текущего состояния, либо инкрементальный апдейт снапшота

В целом это должно быть охуительно быстро и надежно по следующим причинам:
- casual order сообщений легко реплицируется
- запись в персистнтное хранилище идет в виде инсерта, либо отложенного bulk набора изменений, что быстро даже для жестких дисков, не говоря про использование SSD для логов
- данные храняться локально, в БД пишутся минимальные изменения (синхронно) и bulk апдейты (асинхронно). Чтение только при инициализации, либо при cache-miss.
- синхрится все только на выходе из системы, и опционально на входе. Т.е. один или два обязательных insert'а на сообщение, которые вообще говоря могут батчится с другими. Хотя в зависимости от особенностей системы, может потребоваться и асинхронные записи, например для освобождения кэшей, но тут какбэ мало что можно поделать, если памяти не хватает. В норме должно быть один-два инсерта. В случае размещения лога на SSD - это ультра-фаст, типичная задержка легко может быть меньше миллисекунды, и даже можно вести борьбу за меньше сотни мкс (в зависимости от стоимости SSDхи и сетевых интерфейсов).
- по пропускной способности - достижимы миллионы событий в секунду (для маленьких сообщений), хотя для веба вряд ли - в силу большо размера данных, которые нужно перекачать, т.е. тут уже другие боттлнеки

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

  • StatMod и ML

    Рассмотрим, чем полезен StatMod в плане инженерии ML и почему "преподаваемый" ML тут проигрывает. Под "преподаваемым" ML я имею в…

  • Инженерность в DataScience

    Когда я пишу что инженерность в ML слабо развита, это не значит что ее нет вообще. Точнее будет сказать, что в DataScience (некая объемлющая…

  • Основные вопросы в инженерии МЛ

    По своему опыту я выделяю следующие основные вопросы/проблемы, которые возникают при решении практических МЛ задач. Какую задачу мы решаем? Ту ли…

  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 7 comments