ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Как лучше хранить исторические данные?
15 сообщений из 15, страница 1 из 1
Как лучше хранить исторические данные?
    #39517534
G.Collector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
G.Collector
Участник
Всем доброго дня.

Имеется таблица с полями:
ид

дата

метрика

значение

Жирные - составной первичный ключ.

В таблицу в день попадает под 200-300 записей.

Сейчас используется PostgreSQL с еженедельным партицированием на основе наследуемых таблиц и кластерными индексами для заверешнных партиций по полям ид и дата .

В принципе, работает вполне быстро. Существуют какие-нибудь более интересные варианты?
...
Рейтинг: 0 / 0
07.09.2017, 16:16
| Ответить | Цитировать | Написать  
Как лучше хранить исторические данные?
    #39517624
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
G.Collector,

трудно сказать, Вы же свои цели не обозначили

а Вы что ради 1500 записей делаете новую партицию? я бы только с десятка миллионов начал задумываться
...
Рейтинг: 0 / 0
07.09.2017, 17:35
| Ответить | Цитировать | Написать  
Как лучше хранить исторические данные?
    #39517657
G.Collector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
G.Collector
Участник
SergSuper,

простите, ошибся. Имел в виду 200-300 тысяч

цели:
- регулярные выборки метрик по диапазону дат
- регулярные выборки последних N записей для ид->метрики
...
Рейтинг: 0 / 0
07.09.2017, 18:09
| Ответить | Цитировать | Написать  
Как лучше хранить исторические данные?
    #39517685
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
G.Collector,

ну как бы тут очевидно что составной первичный индекс не нужен - первичный должен быть только по id
и должен быть индекс по date

хотя возможно в первичный индекс стоит включить метрику (для второго запроса) если больше никакие поля в запросе не учавствуют
...
Рейтинг: 0 / 0
07.09.2017, 18:55
| Ответить | Цитировать | Написать  
Как лучше хранить исторические данные?
    #39518008
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
G.CollectorВ принципе, работает вполне быстро. Существуют какие-нибудь более интересные варианты?
у постгрес 9 по сути нет partitioning, то что они обозвали партишенингом через check constraints + trigger работает. терминами оракла это partitioned views. так что некст левел это будет платная субд с честным партишенингом, а после него что нибудь из бигдаты. в мире DWH модно сейчас исторические данные на hdfs (читай в hadoop) хранить. я бы поставил докер с one node hadoop cluster, дешевого и гарантированно postgres обгонит на такой задачке уже на одном сервере.
...
Рейтинг: 0 / 0
08.09.2017, 10:16
| Ответить | Цитировать | Написать  
Как лучше хранить исторические данные?
    #39518034
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
Yo.!,

а оно тут надо на таких объемах? я бы например и partitioning даже не делал


самое главное же забыл топикстартеру сказать - если оно нормально работает - не трогай
...
Рейтинг: 0 / 0
08.09.2017, 10:50
| Ответить | Цитировать | Написать  
Как лучше хранить исторические данные?
    #39518036
PgSQLanonymous3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQLanonymous3
Участник
Yo.!G.CollectorВ принципе, работает вполне быстро. Существуют какие-нибудь более интересные варианты?
у постгрес 9 по сути нет partitioning, то что они обозвали партишенингом через check constraints + trigger работает. терминами оракла это partitioned views.Вы не могли бы пояснить, в чём разница на практике (с Oralce не знаком)?

Yo.!так что некст левел это будет платная субд с честным партишенингом, а после него что нибудь из бигдаты.А что такое "честный" partitioning?

Yo.!в мире DWH модно сейчас исторические данные на hdfs (читай в hadoop) хранить. я бы поставил докер с one node hadoop cluster, дешевого и гарантированно postgres обгонит на такой задачке уже на одном сервере.Адекватные сравнения можно где-нибудь посмотреть?
...
Рейтинг: 0 / 0
08.09.2017, 10:53
| Ответить | Цитировать | Написать  
Как лучше хранить исторические данные?
    #39518047
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
SergSuperа оно тут надо на таких объемах? я бы например и partitioning даже не делал

за пару лет 200М+ записей я бы делал, если нет планов через пару лет свалить и переложить ответственность на наследников


PgSQLanonymous3Вы не могли бы пояснить, в чём разница на практике (с Oralce не знаком)?
в том что у PG все тогда идет через дергание CHECK constraint и SQL engin'a, честный как у оракла через gobal index работает.

Yo.!Адекватные сравнения можно где-нибудь посмотреть?
пояснения в сравнении оракла и мсск2000 можно смотреть, вот тут
http://www.oracle.com/technetwork/database/database-technologies/performance/twp-perf-oracle-3.pdf

в мсскл2005 уже честный партишенинг появился, а до 2005 мсскл тоже на CHECK constraints мутил
...
Рейтинг: 0 / 0
08.09.2017, 11:39
| Ответить | Цитировать | Написать  
Как лучше хранить исторические данные?
    #39518050
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
как я понял PG честный партишенинг называет Declarative Partitioning и обещает в конце 2017 выкатить (в 10й версии)
...
Рейтинг: 0 / 0
08.09.2017, 11:46
| Ответить | Цитировать | Написать  
Как лучше хранить исторические данные?
    #39518108
PgSQLanonymous3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQLanonymous3
Участник
Yo.!в том что у PG все тогда идет через дергание CHECK constraint и SQL engin'a, честный как у оракла через gobal index работает.
http://www.oracle.com/technetwork/database/database-technologies/performance/twp-perf-oracle-3.pdf
Познавательно, спасибо.

PgSQLanonymous3Адекватные сравнения можно где-нибудь посмотреть?Я имел в виду c "one node hadoop cluster".
Yo.!как я понял PG честный партишенинг называет Declarative Partitioning и обещает в конце 2017 выкатить (в 10й версии)
Нет, это "те же яйца, вид сбоку". Из документации: "Individual partitions are linked to the partitioned table with inheritance behind-the-scenes".
...
Рейтинг: 0 / 0
08.09.2017, 12:45
| Ответить | Цитировать | Написать  
Как лучше хранить исторические данные?
    #39518196
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
PgSQLanonymous3Я имел в виду c "one node hadoop cluster".

с one node кажется не видел, это скорее из своего опыта. я на своем десктопе хорошо погонял в vmware (16g ram) имиджи от cloudera и hortonworks, такого рода SQL запросы на parquet файлики обгоняли оракл SE га том же десктопе в разы.

PgSQLanonymous3Нет, это "те же яйца, вид сбоку". Из документации: "Individual partitions are linked to the partitioned table with inheritance behind-the-scenes".
похоже на то, а я наивный пару слайдов посмотрел и решил, что Declarative Partitioning отменит тригеры ...
...
Рейтинг: 0 / 0
08.09.2017, 14:16
| Ответить | Цитировать | Написать  
Как лучше хранить исторические данные?
    #39518277
tip78
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tip78
Участник
G.CollectorВсем доброго дня.

Имеется таблица с полями:
ид

дата

метрика

значение

Жирные - составной первичный ключ.

В таблицу в день попадает под 200-300 записей.

Сейчас используется PostgreSQL с еженедельным партицированием на основе наследуемых таблиц и кластерными индексами для заверешнных партиций по полям ид и дата .

В принципе, работает вполне быстро. Существуют какие-нибудь более интересные варианты?

у PG есть тип данных - ranges , где можно хранить даты ОТ - ДО
и даже специальный индекс под них - GiST:
Код: sql
1.
CREATE INDEX ON users USING GIST(tstzrange(created_at,deleted_at));


а также операторы разные , типа: @> (содержит диапазон) int4range(2,4) @> int4range(2,3)
...
Рейтинг: 0 / 0
08.09.2017, 15:26
| Ответить | Цитировать | Написать  
Как лучше хранить исторические данные?
    #39520762
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
G.CollectorВ таблицу в день попадает под 200-300 записей.

В принципе, работает вполне быстро. Существуют какие-нибудь более интересные варианты?
Чел... у тебя вообще все в шоколаде.

Ничего делать не надо. Реально ничего!

Вот если-б по 200-300 млн каждый день... тогда-б надо было-б прокашлять варианты стореджа.
...
Рейтинг: 0 / 0
13.09.2017, 21:46
| Ответить | Цитировать | Написать  
Как лучше хранить исторические данные?
    #39525372
д0kХ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
д0kХ
Гость
PgSQLanonymous3А что такое "честный" partitioning?


Честный партишионинг, это когда в СУБД есть команда
которая за 0.х сек отстегивает от таблицы партицию
в другую таблицу, не перемещая данные физически по датафайлам,
а манипулируя только системными метаданными о объектах БД.
...
Рейтинг: 0 / 0
24.09.2017, 03:07
| Ответить | Цитировать | Написать  
Как лучше хранить исторические данные?
    #39525396
PgSQLanonymous3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQLanonymous3
Участник
д0kХЧестный партишионинг, это когда в СУБД есть команда
которая за 0.х сек отстегивает от таблицы партицию
в другую таблицу, не перемещая данные физически по датафайлам,
а манипулируя только системными метаданными о объектах БД.
Давно есть:
Код: sql
1.
ALTER TABLE measurement_y2006m02 NO INHERIT measurement;

Так что, наверное, речь о чём-то другом.
...
Рейтинг: 0 / 0
24.09.2017, 10:46
| Ответить | Цитировать | Написать  
15 сообщений из 15, страница 1 из 1
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Как лучше хранить исторические данные?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=35&fpage=3&tid=1552234]:
 0ms
get settings:
 8ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 66ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 48ms
get tp. blocked users:
 2ms
others: 14ms
total:  168ms
созд. / загр.: 168ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]