Прозрачный персистенс и 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хи и сетевых интерфейсов).
- по пропускной способности - достижимы миллионы событий в секунду (для маленьких сообщений), хотя для веба вряд ли - в силу большо размера данных, которые нужно перекачать, т.е. тут уже другие боттлнеки
Вот все это щассе хочется уметь программировать с небольшими издержками, а это прежде всего более-менее прозрачное изготовление (инкрементальных) снапшотов. Ибо обработка сообщеий реализуется акторскими языками/библиотеками. Ну а детерминированность - это вопрос дизайна и дисциплины, тут все не так и сложно.
Собсно, на мой взгляд прозрачный персистенс - это не есть База Данных в любом виде. Когда мы пишем код на Жабе или на Скале, мы там не делаем селекты. Хотя конечно обходим коллекции. Вот и такая же идея стоит за прозрачным персистенсом - работаем как обычно с обычными объектами и коллекциями. А прозрачный персистенс отслеживает изменения, при этом делает это в определенные моменты времени.
В принципе, как и куда эти изменения заливаются - это отдельный вопрос.
Вообще имеет смысл прояснить (для себя в первую очередь) общий контекст подхода.
Сейчас в основном господствует 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хи и сетевых интерфейсов).
- по пропускной способности - достижимы миллионы событий в секунду (для маленьких сообщений), хотя для веба вряд ли - в силу большо размера данных, которые нужно перекачать, т.е. тут уже другие боттлнеки
Вот все это щассе хочется уметь программировать с небольшими издержками, а это прежде всего более-менее прозрачное изготовление (инкрементальных) снапшотов. Ибо обработка сообщеий реализуется акторскими языками/библиотеками. Ну а детерминированность - это вопрос дизайна и дисциплины, тут все не так и сложно.