DS
да
Size: a a a
2020 August 12
VS
Бот ты плохой
AK
2020 August 13
AE
Там ещё не хватает выражения clickhouse тормозит)
LY
Приветствую.
Есть намерение прикрутить к тарантулу движки libmdbx и/или libfpta.
Поэтому предварительно интересуюсь кому еще это может быть интересным.
Кратенько о движках:
libmdbx - это key-value на базе b+tree и MVCC (page shadowing), но совсем без WAL.
БД целиком отображается в память и шариться между заинтересованными процессами.
Писатели полностью сериализуются, а для читателей примерно lock-free и линейное масштабирование.
Из-за отсутствия WAL такое не подходит для сценариев с интенсивной записью и необходимостью фиксировать данные на диске, но есть свои плюсы (отсутствие восстановления и merge-выбросов как у LSM), и очень хорошо с чтением.
Исходники = https://github.com/erthink/libmdbx
Документация = https://erthink.github.io/libmdbx, на подходе нативный/удобный интерфейс для С++.
libfpta - это надстройка над libmdbx, реализующая таблички с колонками и индексами.
Без SQL и всяческих излишеств, но в целевых сценариях сильно быстрее SQLite, MySQL и т.п.
https://github.com/erthink/libfpta
Основной предполагаемый сценарий использования:
- есть mdbx-БД, с которой работают несколько локальных процессов, включая один или несколько тарантулов.
- через тарантул обеспечивается доступ из lua-скриптов и через сеть.
- в libfpta будет добавлена "репликация" по мотивам RFC-4533 (синхронизация содержимого).
Неопределенности и сложности:
- можно ограничиться lua-биндингами, но интереснее получить больше от инфраструктуры тарантула.
- в libfpta свои кортежи и пока не ясно как лучше их приклеивать к тарантулу, а может быть и не стоит.
- предполагается поддержка только linux и добавление в libmdbx еще одного механизма синхронизации на базе futex с возможностью использования FUTEX_FD (для неблокирующей синхронизации в фиберах тарантула).
Буду рад ответить на вопросы, но не связанные с тарантулом просьба задавать в https://t.me/libmdbx
Есть намерение прикрутить к тарантулу движки libmdbx и/или libfpta.
Поэтому предварительно интересуюсь кому еще это может быть интересным.
Кратенько о движках:
libmdbx - это key-value на базе b+tree и MVCC (page shadowing), но совсем без WAL.
БД целиком отображается в память и шариться между заинтересованными процессами.
Писатели полностью сериализуются, а для читателей примерно lock-free и линейное масштабирование.
Из-за отсутствия WAL такое не подходит для сценариев с интенсивной записью и необходимостью фиксировать данные на диске, но есть свои плюсы (отсутствие восстановления и merge-выбросов как у LSM), и очень хорошо с чтением.
Исходники = https://github.com/erthink/libmdbx
Документация = https://erthink.github.io/libmdbx, на подходе нативный/удобный интерфейс для С++.
libfpta - это надстройка над libmdbx, реализующая таблички с колонками и индексами.
Без SQL и всяческих излишеств, но в целевых сценариях сильно быстрее SQLite, MySQL и т.п.
https://github.com/erthink/libfpta
Основной предполагаемый сценарий использования:
- есть mdbx-БД, с которой работают несколько локальных процессов, включая один или несколько тарантулов.
- через тарантул обеспечивается доступ из lua-скриптов и через сеть.
- в libfpta будет добавлена "репликация" по мотивам RFC-4533 (синхронизация содержимого).
Неопределенности и сложности:
- можно ограничиться lua-биндингами, но интереснее получить больше от инфраструктуры тарантула.
- в libfpta свои кортежи и пока не ясно как лучше их приклеивать к тарантулу, а может быть и не стоит.
- предполагается поддержка только linux и добавление в libmdbx еще одного механизма синхронизации на базе futex с возможностью использования FUTEX_FD (для неблокирующей синхронизации в фиберах тарантула).
Буду рад ответить на вопросы, но не связанные с тарантулом просьба задавать в https://t.me/libmdbx
TS
Приветствую.
Есть намерение прикрутить к тарантулу движки libmdbx и/или libfpta.
Поэтому предварительно интересуюсь кому еще это может быть интересным.
Кратенько о движках:
libmdbx - это key-value на базе b+tree и MVCC (page shadowing), но совсем без WAL.
БД целиком отображается в память и шариться между заинтересованными процессами.
Писатели полностью сериализуются, а для читателей примерно lock-free и линейное масштабирование.
Из-за отсутствия WAL такое не подходит для сценариев с интенсивной записью и необходимостью фиксировать данные на диске, но есть свои плюсы (отсутствие восстановления и merge-выбросов как у LSM), и очень хорошо с чтением.
Исходники = https://github.com/erthink/libmdbx
Документация = https://erthink.github.io/libmdbx, на подходе нативный/удобный интерфейс для С++.
libfpta - это надстройка над libmdbx, реализующая таблички с колонками и индексами.
Без SQL и всяческих излишеств, но в целевых сценариях сильно быстрее SQLite, MySQL и т.п.
https://github.com/erthink/libfpta
Основной предполагаемый сценарий использования:
- есть mdbx-БД, с которой работают несколько локальных процессов, включая один или несколько тарантулов.
- через тарантул обеспечивается доступ из lua-скриптов и через сеть.
- в libfpta будет добавлена "репликация" по мотивам RFC-4533 (синхронизация содержимого).
Неопределенности и сложности:
- можно ограничиться lua-биндингами, но интереснее получить больше от инфраструктуры тарантула.
- в libfpta свои кортежи и пока не ясно как лучше их приклеивать к тарантулу, а может быть и не стоит.
- предполагается поддержка только linux и добавление в libmdbx еще одного механизма синхронизации на базе futex с возможностью использования FUTEX_FD (для неблокирующей синхронизации в фиберах тарантула).
Буду рад ответить на вопросы, но не связанные с тарантулом просьба задавать в https://t.me/libmdbx
Есть намерение прикрутить к тарантулу движки libmdbx и/или libfpta.
Поэтому предварительно интересуюсь кому еще это может быть интересным.
Кратенько о движках:
libmdbx - это key-value на базе b+tree и MVCC (page shadowing), но совсем без WAL.
БД целиком отображается в память и шариться между заинтересованными процессами.
Писатели полностью сериализуются, а для читателей примерно lock-free и линейное масштабирование.
Из-за отсутствия WAL такое не подходит для сценариев с интенсивной записью и необходимостью фиксировать данные на диске, но есть свои плюсы (отсутствие восстановления и merge-выбросов как у LSM), и очень хорошо с чтением.
Исходники = https://github.com/erthink/libmdbx
Документация = https://erthink.github.io/libmdbx, на подходе нативный/удобный интерфейс для С++.
libfpta - это надстройка над libmdbx, реализующая таблички с колонками и индексами.
Без SQL и всяческих излишеств, но в целевых сценариях сильно быстрее SQLite, MySQL и т.п.
https://github.com/erthink/libfpta
Основной предполагаемый сценарий использования:
- есть mdbx-БД, с которой работают несколько локальных процессов, включая один или несколько тарантулов.
- через тарантул обеспечивается доступ из lua-скриптов и через сеть.
- в libfpta будет добавлена "репликация" по мотивам RFC-4533 (синхронизация содержимого).
Неопределенности и сложности:
- можно ограничиться lua-биндингами, но интереснее получить больше от инфраструктуры тарантула.
- в libfpta свои кортежи и пока не ясно как лучше их приклеивать к тарантулу, а может быть и не стоит.
- предполагается поддержка только linux и добавление в libmdbx еще одного механизма синхронизации на базе futex с возможностью использования FUTEX_FD (для неблокирующей синхронизации в фиберах тарантула).
Буду рад ответить на вопросы, но не связанные с тарантулом просьба задавать в https://t.me/libmdbx
(это моё персональное мнение)
- принести btree движок - это было бы хорошо. Будь то lmdb или libmdbx
- но непонятно что делать с движком без WAL, и как гарантировать хоть что-то, в сценариях с асинхронной и тем более синхронной репликацией в кластере, если у нас нет WAL?
Как вообще изменения с мастера на реплику доносить, если мы полагаемся на ОС в MVCC и оперируем страницами, а не записями?
- принести btree движок - это было бы хорошо. Будь то lmdb или libmdbx
- но непонятно что делать с движком без WAL, и как гарантировать хоть что-то, в сценариях с асинхронной и тем более синхронной репликацией в кластере, если у нас нет WAL?
Как вообще изменения с мастера на реплику доносить, если мы полагаемся на ОС в MVCC и оперируем страницами, а не записями?
MA
Похоже это история как с Sofia
MA
Само по себе круто, но от склейки с тарантулом больше проблем, сложностей в эксплуатации и написании кода, чем пользы
TS
Похоже это история как с Sofia
К своему стыду, я не в курсе истории про Софию. Что там было?
MA
К своему стыду, я не в курсе истории про Софию. Что там было?
Теперь это винил
LY
(это моё персональное мнение)
- принести btree движок - это было бы хорошо. Будь то lmdb или libmdbx
- но непонятно что делать с движком без WAL, и как гарантировать хоть что-то, в сценариях с асинхронной и тем более синхронной репликацией в кластере, если у нас нет WAL?
Как вообще изменения с мастера на реплику доносить, если мы полагаемся на ОС в MVCC и оперируем страницами, а не записями?
- принести btree движок - это было бы хорошо. Будь то lmdb или libmdbx
- но непонятно что делать с движком без WAL, и как гарантировать хоть что-то, в сценариях с асинхронной и тем более синхронной репликацией в кластере, если у нас нет WAL?
Как вообще изменения с мастера на реплику доносить, если мы полагаемся на ОС в MVCC и оперируем страницами, а не записями?
Пока точно нет намерения делать из mdbx полноценный движок хранения для тарантула, в частности с поддержкой реплик и т.п. Ибо с этим действительно связана масса архитектурных проблем и необходимостью проводить глубокие изменения как в тарантуле, так и в libmdbx.
AK
Приветствую.
Есть намерение прикрутить к тарантулу движки libmdbx и/или libfpta.
Поэтому предварительно интересуюсь кому еще это может быть интересным.
Кратенько о движках:
libmdbx - это key-value на базе b+tree и MVCC (page shadowing), но совсем без WAL.
БД целиком отображается в память и шариться между заинтересованными процессами.
Писатели полностью сериализуются, а для читателей примерно lock-free и линейное масштабирование.
Из-за отсутствия WAL такое не подходит для сценариев с интенсивной записью и необходимостью фиксировать данные на диске, но есть свои плюсы (отсутствие восстановления и merge-выбросов как у LSM), и очень хорошо с чтением.
Исходники = https://github.com/erthink/libmdbx
Документация = https://erthink.github.io/libmdbx, на подходе нативный/удобный интерфейс для С++.
libfpta - это надстройка над libmdbx, реализующая таблички с колонками и индексами.
Без SQL и всяческих излишеств, но в целевых сценариях сильно быстрее SQLite, MySQL и т.п.
https://github.com/erthink/libfpta
Основной предполагаемый сценарий использования:
- есть mdbx-БД, с которой работают несколько локальных процессов, включая один или несколько тарантулов.
- через тарантул обеспечивается доступ из lua-скриптов и через сеть.
- в libfpta будет добавлена "репликация" по мотивам RFC-4533 (синхронизация содержимого).
Неопределенности и сложности:
- можно ограничиться lua-биндингами, но интереснее получить больше от инфраструктуры тарантула.
- в libfpta свои кортежи и пока не ясно как лучше их приклеивать к тарантулу, а может быть и не стоит.
- предполагается поддержка только linux и добавление в libmdbx еще одного механизма синхронизации на базе futex с возможностью использования FUTEX_FD (для неблокирующей синхронизации в фиберах тарантула).
Буду рад ответить на вопросы, но не связанные с тарантулом просьба задавать в https://t.me/libmdbx
Есть намерение прикрутить к тарантулу движки libmdbx и/или libfpta.
Поэтому предварительно интересуюсь кому еще это может быть интересным.
Кратенько о движках:
libmdbx - это key-value на базе b+tree и MVCC (page shadowing), но совсем без WAL.
БД целиком отображается в память и шариться между заинтересованными процессами.
Писатели полностью сериализуются, а для читателей примерно lock-free и линейное масштабирование.
Из-за отсутствия WAL такое не подходит для сценариев с интенсивной записью и необходимостью фиксировать данные на диске, но есть свои плюсы (отсутствие восстановления и merge-выбросов как у LSM), и очень хорошо с чтением.
Исходники = https://github.com/erthink/libmdbx
Документация = https://erthink.github.io/libmdbx, на подходе нативный/удобный интерфейс для С++.
libfpta - это надстройка над libmdbx, реализующая таблички с колонками и индексами.
Без SQL и всяческих излишеств, но в целевых сценариях сильно быстрее SQLite, MySQL и т.п.
https://github.com/erthink/libfpta
Основной предполагаемый сценарий использования:
- есть mdbx-БД, с которой работают несколько локальных процессов, включая один или несколько тарантулов.
- через тарантул обеспечивается доступ из lua-скриптов и через сеть.
- в libfpta будет добавлена "репликация" по мотивам RFC-4533 (синхронизация содержимого).
Неопределенности и сложности:
- можно ограничиться lua-биндингами, но интереснее получить больше от инфраструктуры тарантула.
- в libfpta свои кортежи и пока не ясно как лучше их приклеивать к тарантулу, а может быть и не стоит.
- предполагается поддержка только linux и добавление в libmdbx еще одного механизма синхронизации на базе futex с возможностью использования FUTEX_FD (для неблокирующей синхронизации в фиберах тарантула).
Буду рад ответить на вопросы, но не связанные с тарантулом просьба задавать в https://t.me/libmdbx
А какой практический смысл? Что дают эти движки из того, чего не хватает Тарантулу?
AB
разделения между процессами, видимо
AB
но смысл
MA
Прочитал описание бд.
Подход интересный, перф выше, чем у софии, при этом оптимизация на чтение делает из этой бд гораздо более интересный инструмент.
Теоретически, я бы использовал этот движок как disk backed local storage в рамках одной ноды.
Либо для кеша, либо с реализацией ручной репликации (например как сцилле) при помощи аппсервера тарантула
Подход интересный, перф выше, чем у софии, при этом оптимизация на чтение делает из этой бд гораздо более интересный инструмент.
Теоретически, я бы использовал этот движок как disk backed local storage в рамках одной ноды.
Либо для кеша, либо с реализацией ручной репликации (например как сцилле) при помощи аппсервера тарантула
MA
@akudiyar @arturbrsg смысл в дисковом движке, из которого можно нормально читать (в отличие от винила)
AB
а, он дисковый
LY
А какой практический смысл? Что дают эти движки из того, чего не хватает Тарантулу?
У меня (Positive Technologies) есть ряд сценариев, где сейчас используется libmdbx и libdfpta.
И вот на горизонте видны сценарии где добавление условного тарантула будет очень хорошо - как минимум в виде "агенда доступа к БД".
И вот на горизонте видны сценарии где добавление условного тарантула будет очень хорошо - как минимум в виде "агенда доступа к БД".
LY
Прочитал описание бд.
Подход интересный, перф выше, чем у софии, при этом оптимизация на чтение делает из этой бд гораздо более интересный инструмент.
Теоретически, я бы использовал этот движок как disk backed local storage в рамках одной ноды.
Либо для кеша, либо с реализацией ручной репликации (например как сцилле) при помощи аппсервера тарантула
Подход интересный, перф выше, чем у софии, при этом оптимизация на чтение делает из этой бд гораздо более интересный инструмент.
Теоретически, я бы использовал этот движок как disk backed local storage в рамках одной ноды.
Либо для кеша, либо с реализацией ручной репликации (например как сцилле) при помощи аппсервера тарантула
Как-бы "репликацию" я точно будут делать "свою" (вне зависимости от интеграции с тарантулом) и точно по мотивам LDAP-овского https://pro-ldap.ru/tr/rfc/rfc4533.html
И тут фишка в том, что это не совсем репликация, а именно "синхронизация содержимого" со своими плюсами и минусами. В частности, может работать без журнала, но на репликах в отдельных фазах нет границ транзакций, кои были на мастере.
P.S.
Мне пришлось чинить подобную байду (ReOpenLDAP) для МегаФона, до того как там перешли на таранул.
И тут фишка в том, что это не совсем репликация, а именно "синхронизация содержимого" со своими плюсами и минусами. В частности, может работать без журнала, но на репликах в отдельных фазах нет границ транзакций, кои были на мастере.
P.S.
Мне пришлось чинить подобную байду (ReOpenLDAP) для МегаФона, до того как там перешли на таранул.
LY
@akudiyar @arturbrsg смысл в дисковом движке, из которого можно нормально читать (в отличие от винила)
Не понял реплики.
На всякий:
- у libmdbx основная фишка в минимальном оверхеде при доступе из "роя" локальных процессов.
- чтение не блокируется (после регистрации треда-читателя не блокируется совсем), масштабируется по ядрам (пока не упирается в memory bandwidth) и обычно чуть быстрее чем std::map (из-за большей локальности).
На всякий:
- у libmdbx основная фишка в минимальном оверхеде при доступе из "роя" локальных процессов.
- чтение не блокируется (после регистрации треда-читателя не блокируется совсем), масштабируется по ядрам (пока не упирается в memory bandwidth) и обычно чуть быстрее чем std::map (из-за большей локальности).