История изменений
Исправление sanyo1234, (текущая версия) :
В том, что это всё должно работать в реальном времени (чтение/запись) на скоростях под 50 ГБ/с на одном сервере без репликации. Мускуль и постгрес не умеет работать с RAM+NVME и кластером из HDD одновременно. Они не знают какие данные кешировать в NVME, какие оставить в RAM, а какие отложить на задворки HDD. Они не умеют в констрейнты на джаве в одной JVM с приложением и не знают текующие потребности этого приложения. Я уже не говорю о синхронизации схемы БД и домена классов на джаве.
Это не решается построением архитектуры с использованием различных компонентов, которые умеют в кэширование на соответствующих устройствах?
Самое простое - это уже готовая СУБД поверх ZFS, где включен L2ARC и SLOG на SSD, а остальные vdevs на HDD ? Про 50 GB/s не уверен и у ZFS есть проблема с относительно быстрой фрагментацией на рандомной нагрузке типа СУБД, но можно дефрагментировать через send | receive, если хватает железяк под это.
Почему-то я сомневаюсь, что ты сделаешь лучше.
Кроме того у нормальных СУБД есть так называемая feature: «multi-temperature storage».
https://www.ibm.com/support/producthub/db2/docs/content/SSEPGG_11.5.0/com.ibm...
Исправление sanyo1234, :
В том, что это всё должно работать в реальном времени (чтение/запись) на скоростях под 50 ГБ/с на одном сервере без репликации. Мускуль и постгрес не умеет работать с RAM+NVME и кластером из HDD одновременно. Они не знают какие данные кешировать в NVME, какие оставить в RAM, а какие отложить на задворки HDD. Они не умеют в констрейнты на джаве в одной JVM с приложением и не знают текующие потребности этого приложения. Я уже не говорю о синхронизации схемы БД и домена классов на джаве.
Это не решается построением архитектуры с использованием различных компонентов, которые умеют в кэширование на соответствующих устройствах?
Самое простое - это уже готовая СУБД поверх ZFS, где включен L2ARC и SLOG на SSD, а остальные vdevs на HDD ? Про 50 GB/s не уверен и у ZFS есть проблема с относительно быстрой фрагментацией на рандомной нагрузке типа СУБД, но можно дефрагментировать через send | receive, если хватает железяк под это.
Почему-то я сомневаюсь, что ты сделаешь лучше.
Исправление sanyo1234, :
В том, что это всё должно работать в реальном времени (чтение/запись) на скоростях под 50 ГБ/с на одном сервере без репликации. Мускуль и постгрес не умеет работать с RAM+NVME и кластером из HDD одновременно. Они не знают какие данные кешировать в NVME, какие оставить в RAM, а какие отложить на задворки HDD. Они не умеют в констрейнты на джаве в одной JVM с приложением и не знают текующие потребности этого приложения. Я уже не говорю о синхронизации схемы БД и домена классов на джаве.
Это не решается построением архитектуры с использованием различных компонентов, которые умеют в кэширование на соответствующих устройствах?
Самое простое - это СУБД поверх ZFS, где включен L2ARC и SLOG на SSD, а остальные vdevs на HDD ? Про 50 GB/s не уверен и у ZFS есть проблема с относительно быстрой фрагментацией на рандомной нагрузке типа СУБД, но можно дефрагментировать через send | receive, если хватает железяк под это.
Исходная версия sanyo1234, :
В том, что это всё должно работать в реальном времени (чтение/запись) на скоростях под 50 ГБ/с на одном сервере без репликации. Мускуль и постгрес не умеет работать с RAM+NVME и кластером из HDD одновременно. Они не знают какие данные кешировать в NVME, какие оставить в RAM, а какие отложить на задворки HDD. Они не умеют в констрейнты на джаве в одной JVM с приложением и не знают текующие потребности этого приложения. Я уже не говорю о синхронизации схемы БД и домена классов на джаве.
Это не решается построением архитектуры с использованием различных компонентов, которые умеют в кэширование на соответствующих устройствах?
Самое простое - это СУБД поверх ZFS, где включен L2ARC и SLOG ? Про 50 GB/s не уверен и у ZFS есть проблема с относительно быстрой фрагментацией на рандомной нагрузке типа СУБД, но можно дефрагментировать через send | receive, если хватает железяк под это.