То есть требований транзакционности нет, чисто заливать данные, и на них онолитегу гонять? Сколько данных, какое время отклика требуется? Надо ли, чтобы время простоя было околонулевое, поддержка нескольких вычислительных центров?
Если всё влезает в одну машину, так это детский сад.
Теплое vs мягкое.
Если у вас нет ограничений на количество машин, то вы можете прекрасно обойтись без колоночных индексов. Добавляйте ноды и вперед.
Если у вам надо резко увеличить производительность аналитических запросов, не добавляя железа, то columnar storage чаще всего может помочь.
Если всё влезает в одну машину, так это детский сад.
Просто не биг дата.
В моем случае дата не биг. А медиум. Но она должна пересчитываться каждые 5 минут. И апдейтаться как тока происходят изменения. А изменения бывают двух видов - позиционные и рыночные.
Если всё влезает в одну машину, так это детский сад.
Просто не биг дата.
В моем случае дата не биг. А медиум. Но она должна пересчитываться каждые 5 минут. И апдейтаться как тока происходят изменения. А изменения бывают двух видов - позиционные и рыночные.
возможна кластеризация по разным ассетам.
Значит тебе колумнар сторадж не подходит. Если дата не биг, надо все грузить in-memory, тогда пофиг колумнар неколумнар.
Просто не биг дата.
В моем случае дата не биг. А медиум. Но она должна пересчитываться каждые 5 минут. И апдейтаться как тока происходят изменения. А изменения бывают двух видов - позиционные и рыночные.
возможна кластеризация по разным ассетам.
Значит тебе колумнар сторадж не подходит. Если дата не биг, надо все грузить in-memory, тогда пофиг колумнар неколумнар.
Просто не биг дата.
В моем случае дата не биг. А медиум. Но она должна пересчитываться каждые 5 минут. И апдейтаться как тока происходят изменения. А изменения бывают двух видов - позиционные и рыночные.
возможна кластеризация по разным ассетам.
Значит тебе колумнар сторадж не подходит. Если дата не биг, надо все грузить in-memory, тогда пофиг колумнар неколумнар.
Не совсем. Memory locality всё равно рулит. И чем дальше, тем больше.
voyager3 писал(а): ↑Вс сен 08, 2024 10:00 am
Не совсем. Memory locality всё равно рулит. И чем дальше, тем больше.
Фишка в том, что обычные row таблицы грузятся in-memory как columnar, и даже могут грузится две копии row-oriented в buffer cache, и columnar-oriented в in-memory. В общем варианты есть.
Буратино писал(а): ↑Вс сен 08, 2024 10:15 am
Фишка в том, что обычные row таблицы грузятся in-memory как columnar, и даже могут грузится две копии row-oriented в buffer cache, и columnar-oriented в in-memory. В общем варианты есть.
В зависимости от хитроумия формата хранения, с predicate pushdown и pre-aggregation, и RLE, с родным столбцовым форматом есть шансы, что и не надо будет грузить в память.
Bobeg писал(а): ↑Вс сен 08, 2024 9:45 am
В моем случае дата не биг. А медиум. Но она должна пересчитываться каждые 5 минут. И апдейтаться как тока происходят изменения. А изменения бывают двух видов - позиционные и рыночные.
возможна кластеризация по разным ассетам.
Тогда колоночная память скорей всего не подойдет - она плохо упдайтется. Если вы смотрите за интрадей изменениями своего портфеля и пересчитываете на ходу греков, вар, пнл и пр. то длинная аналитика вам тоже не нужна.
Инмемори - это ваш путь
