Обсуждение: Re: [pgsql-ru-general] hstore & plperl & массивы

DI> Я не знаком с Perl, но очевидно, что эта задача решается намного проще,
DI> чем может показаться:
DI> http://www.depesz.com/index.php/2008/10/04/
DI> deserialization-of-hstore-data-structure-in-perl/

это парсинг, собственно хочется не парсингом заниматься (ибо хорошо бы
оставить работу с собственно RAW строкой на откупе у "родного"
движка),  а потому наверно лучше попытаться подергать из perl функции
*keys  и *vals? как впрочем и из других языков. ну я в общем покопаюсь
на этом направлении: можно ли из plperl дергать функции C/plpgsql


DI> Не совсем понятно какая решается задача.

ну есть поле - массив hstore.
в это поле иногда делается append новой hstore. хочется массив держать
упорядоченным по одному из ключей этих hstore. то есть вместо append
делать insert в нужное место.

соответственно чтобы его делать нужен бинарный поиск по массиву.
я его сам конечно написал на plpgsql но возможно это очередной велик и
есть что-то готовое?
--

. ''`.                               Dmitry E. Oboukhov
: :’  :   email: unera@debian.org jabber://UNera@uvw.ru
`. `~’              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537

DI> Не совсем понятно, зачем нужен упорядоченный по ключу массив hstore?
DI> Да и вообще, куда принципиально помещать элементы такого массива, если
DI> у них отсутствует ключ, по котору производится упорядочивание?
DI> Возможно, здесь не совсем продуманное проектное решение.

ну примерно так: работает прибор, передает данные на сервер. сервер
добавляет эти данные в массив hstore.
прибор снимает точки 1. 2. 3. ...
но при передаче точки могут прийти так 2. 1. 3. ... (если не удалось
передать точку, делаются повторы итп)

можно конечно точки сортировать в момент их выборки, а можно в момент
помещения точки в массив точек. как-то так :)
--

. ''`.                               Dmitry E. Oboukhov
: :’  :   email: unera@debian.org jabber://UNera@uvw.ru
`. `~’              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537

DI> Какой смысл использовать массив, когда можно просто
DI> добавлять данные в таблицу в хронологическом порядке?
DI> Причём хронологию будет фиксировать сама СУБД (очень просто
DI> достижимо использованием now() в качестве значения по умолчанию).

ну смысл простой:
1. данные преимущественно выбираются только скопом (очень редко из
скопа делается срез, но тут можно сделать unnest), на уровне тех
скопов которыми они выбираются они и группируются в массивы.
то есть по сути массив измерений - одна сущность :)

2. выбор таблица на 500 тыс строк vs таблица на 5-50 млн строк, при том
что индексы нафиг там не нужны (включая PRIMARY KEY) пихает прямо в
направлении использования массива в столбике :). а когда там станет 5
млн строк, то распакованная таблица будет 50-500 млн. 5 млн это еще
тот размер который в случае чего быстро (относительно)
восстанавливается после сбоев (я правда со сбоями на постгрисе не
работал, а на mysql мы от этого порога начинали таблицы дробить на
более мелкие)
--

. ''`.                               Dmitry E. Oboukhov
: :’  :   email: unera@debian.org jabber://UNera@uvw.ru
`. `~’              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537

DI> В данном случае сущность - это измерение.
ну эта сущность тоже хранится в виде одного элемента hstore.
а если уж буквоедствовать, то сущность - элемент внутри hstore, только
мы же все равно пользуемся им там где он удобнее? ;)


DI> Лично я вообще бы не стал задумываться над тем, сколько строк будет
DI> содержать таблица, потому что таких ограничений PostgreSQL не накладывает
DI> (есть лимит размера таблицы - 32 ТБ).

а в случае сбоя диска (например) восстановление таблицы 5 млн строк vs
восстановление таблицы 500 тыс строк насколько отличается?

в MySql при таблицах одинакового размера (в смысле в мегабайтах)
таблица содержащая больше строк банально дольше восстанавливается
после сбоя. а так же заливка дампа итп тоже дольше.

на цифрах ~5 млн времена необходимые на ликвидацию последствий сбоя
начинают измеряться часами.

понятно что сбои - нештатная ситуация, но всякое бывает, бывает что
хостер и электричество рубит...

DI> Хранение данных в таблице в
DI> классическом виде, где каждая строка представляет отдельную сущность,
DI> предоставляет всю мощь реляционных БД, поэтому, на мой взгляд,
DI> является предпочтительным всегда.
ну тогда и hstore предпочтительно хранить в таблице |name|value|
или даже |name_id|value| только это уже будет перебор :)

DI> Но видимо Вы не один, кого заботит этот вопрос (и на то есть, конечно,
DI> причины).
DI> Поэтому PostgreSQL явно поддерживает разделение таблиц на несколько.
DI> Подробности здесь -
DI> http://www.postgresql.org/docs/9.0/static/ddl-partitioning.html

да я это читал, планирую применить это в перспективе.
как я понимаю в любой момент любую таблицу можно сделать родительской
для другой и перенести часть данных в эту другую таблицу :)

DI> PS. Я не настаиваю на том, что моё мнение является единственным правильным,
DI> ибо вера в единственно правильное решение является детской болезнью (хотя
DI> этим часто страдают и взрослые) :-)
DI> И поэтому в любом случае проектное решение остаётся только за Вами.

Я очень Вам благодарен за те советы что Вы мне дали (и надеюсь будете
продолжать давать). Я пока только осваиваю Pg и постоянно наталкиваюсь
на то что мой имеющийся опыт тут либо вреден либо не нужен :)


DI> PPS. В PostgreSQL нет функции сотрировки массивов с использованием
DI> оператора упорядочивания, определяемого пользователем.

ну можно всегда сделать unnest -> order by -> array_agg на самом деле
:)

--

. ''`.                               Dmitry E. Oboukhov
: :’  :   email: unera@debian.org jabber://UNera@uvw.ru
`. `~’              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537

On 03/11/11 16:03, Dmitry E. Oboukhov wrote:
> а в случае сбоя диска (например) восстановление таблицы 5 млн строк vs
> восстановление таблицы 500 тыс строк насколько отличается?
Может, RAID?

DI> Бывает, конечно, всякое. И по улицам ночью ходить может быть опасно и т.д.
DI> Тем не менее, я считаю, что опасения по поводу восстановления после
DI> сбоев обоснованы, но не должны выходить на передний план при проектировании.

а они и не выходят (как основной фактор во всяком случае).
суть складирования в массивы в том что эти массивы именно массивами и
нужно по бизнес-логике выбирать и поиск внутри этих массивов не нужен.
ну а то что в кач-ве профита получили еще и возможность на пару
порядков  сократить число строк в таблице - хороший плюс :)

DI> Начиная с 9.0, аггрегирующие функции поддерживают ORDER BY. Т.о., можно
DI> и того проще, например
DI> dmitigr=> SELECT array_agg(fname ORDER BY id DESC) FROM test;

и зачем я столько лет убил на возню с MySQL? ;)
--

. ''`.                               Dmitry E. Oboukhov
: :’  :   email: unera@debian.org jabber://UNera@uvw.ru
`. `~’              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537

>> а в случае сбоя диска (например) восстановление таблицы 5 млн строк vs
>> восстановление таблицы 500 тыс строк насколько отличается?
ANO> Может, RAID?

креши таблиц бывают не только по причине дисков. это может быть как
уборщица которую неожиданно черт принес, таки и хостинг на агаве где
любят электричество повырубать на работающих под нагрузкой серваках :)
--

. ''`.                               Dmitry E. Oboukhov
: :’  :   email: unera@debian.org jabber://UNera@uvw.ru
`. `~’              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537