срм на колоночной бд. однако...

Ну, если хранить данные статистические, почему нет?

А в 2007 еще црм новые начинаюи?

на Go ))0))00)

да да. я понимаю. поэтому и предлагаю ассемблер. уж если городить то сразу везде.

А в 2007 еще црм новые начинаюи?

Ну, маленькие организации не начинают, очевидно :)

Сразу оптимально чтобы

А если у организации есть всякая сложная специфика с производством под конкретный запрос. То почему бы не сделать свой идеальный велосипед? ;)

А если у организации есть всякая сложная специфика с производством под конкретный запрос. То почему бы не сделать свой идеальный велосипед? ;)

ахаха, тоесть мяу

А если у организации есть всякая сложная специфика с производством под конкретный запрос. То почему бы не сделать свой идеальный велосипед? ;)

можно не дожить

Тем более, что сдвиг платформы. 1С надоела, Web и мобилки - модно. Что тут думать. Надо делать )

можно не дожить

Это да ?

Надо брать ОроПлатформ )

Всем привет. Ребят, столкнулся с такой ошибкой. Exception 'yii\db\Exception' with message 'SQLSTATE[08006] [7] fe_sendauth: no password supplied' Гугл ничего не говорит((

Всем привет. Ребят, столкнулся с такой ошибкой. Exception 'yii\db\Exception' with message 'SQLSTATE[08006] [7] fe_sendauth: no password supplied' Гугл ничего не говорит((

https://www.postgresql.org/docs/9.6/static/errcodes-appendix.html

только сегодня и только для вас. друг просил помочь. вкладка в браузере была открыта

только сегодня и только для вас. друг просил помочь. вкладка в браузере была открыта

спасибо)))

08006 connection_failure

08006 connection_failure

ну это что-то типа ошибка соединения?

у нас было другое приключение. как этот SQLSTATE смотреть в libpq в Сях

ну это что-то типа ошибка соединения?

ды

у нас было другое приключение. как этот SQLSTATE смотреть в libpq в Сях

а может быть из-за отсутствия пароля?

хз. я не пользуюсь обертками фреймворков. либо редко.

это коннект. либо порт не тот. либо еще что

это коннект. либо порт не тот. либо еще что

понял спасибо))

Всем привет. Ребят, столкнулся с такой ошибкой. Exception 'yii\db\Exception' with message 'SQLSTATE[08006] [7] fe_sendauth: no password supplied' Гугл ничего не говорит((

Сервер ожидает пароля при подключении, но пароль не был предоставлен. Надо настраивать pg_hba.conf, если пароль не нужно передавать

не факт. это именно коннект. иначе бы вылезла ошибка по авторизации. в перечне есть

хотя мой ругаицо. клиенд

Сервер ожидает пароля при подключении, но пароль не был предоставлен. Надо настраивать pg_hba.conf, если пароль не нужно передавать

проще с паролем сделать?)

смотря, что вам нужно, если пароль не нужен, то в pg_hba.conf нужно указать строку типа: # IPv4 local connections: host all all 0.0.0.0/0 trust

дадада и порт наружу и нам всем сказать

смотря, что вам нужно, если пароль не нужен, то в pg_hba.conf нужно указать строку типа: # IPv4 local connections: host all all 0.0.0.0/0 trust

проще пароль поставить)

А так же блокирует таблицу при вставке

не первый год уже как нет

не первый год уже как нет

Тогда я не в курсе, чем достигается атомарность? Copy on write?

изучу этот вопрос

Да черт его знает, просто пинать ее за collection-level lock было модно черт знает в каком году. "For most read and write operations, WiredTiger uses optimistic concurrency control. WiredTiger uses only intent locks at the global, database and collection levels. When the storage engine detects conflicts between two operations, one will incur a write conflict causing MongoDB to transparently retry that operation." - видимо оно, https://docs.mongodb.com/manual/faq/concurrency/

(чуть выше на той же странице пишется, что wired tiger использует document-level lock)

Да черт его знает, просто пинать ее за collection-level lock было модно черт знает в каком году. "For most read and write operations, WiredTiger uses optimistic concurrency control. WiredTiger uses only intent locks at the global, database and collection levels. When the storage engine detects conflicts between two operations, one will incur a write conflict causing MongoDB to transparently retry that operation." - видимо оно, https://docs.mongodb.com/manual/faq/concurrency/

Я ее еще за кое-какие другие свойства пинаю =) Например за долгий limit offset

А где он быстрый?

В пг быстрее

Намного

делал лимит оффсет с записи номер 24 050 000 по запись с 24 051 000 - около 10 минут

если не больше

тоже самое в пг - это секунды

А длина строки в пг какая в таблице была?

Выглядит космически как-то

не то чтобы я защищаю монгу, но где вы собрались получать двадцатичетырехтысячную страницу?

24 050 000 — он же прошерстит все эти строки, пока дойдёт до нужной

да, а где это реально применять вообще?

А длина строки в пг какая в таблице была?

Не считал длинну строки. Но могу сказать, что структура данных была аналогична монговскому документу. Десять полей int64, два поля TEXT, примерно по 20 символов.

у вас есть пользователи, которые прочитали предыдущие двадцать четыре тысячи страниц?

да, а где это реально применять вообще?

хз, мне просто любопытны результаты работы limit offset

да, а где это реально применять вообще?

Применение у нас это список с паджинацией. Но реально никто до той страницы не доходит. Пришлось применить такой лимит оффсет, когда мигрировал с монги на пг

Не знаю, как в пг реализованно, может он хранит данные пачками, и высчитывает номер пачки и уже от нее считает лимит оффсет

а не шерстит все записи

Я, конечно, не разработчик баз данных, но, наверное делал бы как-то так

120 байт на строку без учёта оверхеда, т.е. примерно по 65 записей на страницу, т.е. hit'ов было примерно ~370000

Ну в целом не очень долго должно было быть, да, если на SSD крутилось всё

не hdd

а не шерстит все записи

Не, он шерстит, к сожалению :/

где-то видел статью, вроде на хабре - в аннотации было написано, что-то вроде пг космос, у него быстрый лимит оффсет и какие-то замеры далее

надо найти

По идее если есть индекс + сортировка, то можно было бы использовать индекс для выбора страниц (bitmap scan), чтобы не шерстить весь хип. Не знаю, есть ли такое в пг. Можно попробовать

*Даже не bitmap, а обычный индекс скан

Да можно в принципе, да. Неприятности начинаются при фильтрации какой-нибудь.

ERROR: S client not available

пожалуй да. Но если использовать покрывающий индекс из pgpro, то это тоже можно обойти (правда ценой пожирневшего индекса)

кстати, а чем глобально покрывающий индекс из pgpro отличается от составного индекса по тем же полям?

я не знаю наверняка, как он устроен (@alubennikova_pgpro возможно поделится мудростью), но я так понимаю, что он должен быть компактнее, т.к. неключевые поля хранятся в листьях, эти поля не участвуют в поиске ключа (меньше операций сравнения), а также не мешают сделать unique констрейнт

Привет. Подскажите, есть таблица-лог, в ней есть поля условно object_type, object_id,create_time. Таблица довольно большая, пара сотен миллионов записей. За месяц примерно 5 млн. Хочется быстро выбирать из таблицы записи определенного типа и с определенными object_id за, допустим, месяц. На таблице уже есть индекс по create_time Но он работает не очень быстро. Важно, что примерно 90% записей имеют type = 'type1', который меня не сильно интересует. Я создал индекс по ( object_type, create_time ) where object_type <> 'type1'. Пытаюсь сделать запрос по object_type и create_time, но в плане все равно используется медленный индекс только по create_time. Если удалить индекс по create_time, то запрос идёт по нужному мне индексу и гораздо быстрее. Вопрос: почему так и можно ли на это повлиять как-то?

Привет. Подскажите, есть таблица-лог, в ней есть поля условно object_type, object_id,create_time. Таблица довольно большая, пара сотен миллионов записей. За месяц примерно 5 млн. Хочется быстро выбирать из таблицы записи определенного типа и с определенными object_id за, допустим, месяц. На таблице уже есть индекс по create_time Но он работает не очень быстро. Важно, что примерно 90% записей имеют type = 'type1', который меня не сильно интересует. Я создал индекс по ( object_type, create_time ) where object_type <> 'type1'. Пытаюсь сделать запрос по object_type и create_time, но в плане все равно используется медленный индекс только по create_time. Если удалить индекс по create_time, то запрос идёт по нужному мне индексу и гораздо быстрее. Вопрос: почему так и можно ли на это повлиять как-то?

Партиционирование?

Привет. Подскажите, есть таблица-лог, в ней есть поля условно object_type, object_id,create_time. Таблица довольно большая, пара сотен миллионов записей. За месяц примерно 5 млн. Хочется быстро выбирать из таблицы записи определенного типа и с определенными object_id за, допустим, месяц. На таблице уже есть индекс по create_time Но он работает не очень быстро. Важно, что примерно 90% записей имеют type = 'type1', который меня не сильно интересует. Я создал индекс по ( object_type, create_time ) where object_type <> 'type1'. Пытаюсь сделать запрос по object_type и create_time, но в плане все равно используется медленный индекс только по create_time. Если удалить индекс по create_time, то запрос идёт по нужному мне индексу и гораздо быстрее. Вопрос: почему так и можно ли на это повлиять как-то?

analyze таблице делали? :)

Партиционирование?

Плюсану. Автоматическое, по дате. И хранимки для извлечения.

Привет. Подскажите, есть таблица-лог, в ней есть поля условно object_type, object_id,create_time. Таблица довольно большая, пара сотен миллионов записей. За месяц примерно 5 млн. Хочется быстро выбирать из таблицы записи определенного типа и с определенными object_id за, допустим, месяц. На таблице уже есть индекс по create_time Но он работает не очень быстро. Важно, что примерно 90% записей имеют type = 'type1', который меня не сильно интересует. Я создал индекс по ( object_type, create_time ) where object_type <> 'type1'. Пытаюсь сделать запрос по object_type и create_time, но в плане все равно используется медленный индекс только по create_time. Если удалить индекс по create_time, то запрос идёт по нужному мне индексу и гораздо быстрее. Вопрос: почему так и можно ли на это повлиять как-то?

Индекс по типу смысла не имеет. У него селективность получается как его нет.

analyze таблице делали? :)

Вроде делал, но не спасло :(

Индекс по типу смысла не имеет. У него селективность получается как его нет.

Почему? У него ведь и create_time тоже присутствует.

ну вот если оно внего полезет то сначала будет перебирать адову тучу данных одного типа а потом уже выбирать время.

причем в поиск загребется и то где время не нужное.

индекс по типу в таких случаях не имеет смысла

один хрен ты тащиш временными интервалами и уже из ограниенного набора выгребаешь данные нужного типа. так быстрее

за тебя постгрес и решил как ему быстрее. правильно решил

а индекс тип-время можешь дропнуть. только табличку замедляешь

индекс время-тип пробовали? :)

а зачем?

у тебя вторая половина его не будет работать

ну вот если оно внего полезет то сначала будет перебирать адову тучу данных одного типа а потом уже выбирать время.

Поэтому партиционировать надо по типу объекта, что б в тип1 вообще (почти) не соваться. И положить эту партицию на хдд, а которая не тип1 на ссд. И ваши волосы будут шелковистыми

в случае лога нао по времени партицировать )

он один хрен будет интервалами тащить )

Короче вариантов развития событий несколько и без стакана^wдеталей не разберёшься )

в случае лога нао по времени партицировать )

на первом уровне по времени, на втором - по типу )

на первом уровне по времени, на втором - по типу )

ну это зависит от того как и что аффтару надо извлекать

ну поскольку у аффтара это лог, то время скорее всего будет присутствовать в запросе почти всегда

ну вот и я про то. у него появляется ограничение выборки

https://www.postgresql.org/docs/9.6/static/row-estimation-examples.html

чо там мануал говорит

selectivity = (1 + (1000 - bucket[2].min)/(bucket[2].max - bucket[2].min))/num_buckets = (1 + (1000 - 993)/(1997 - 993))/10 = 0.100697