Давайте все хранить в текстовых файлах, это же так удобно.?

Если нам не нужны свойства RDBMS, давайте, почему же нет? Про unix-way слышали? Так вот это — один из его компонентов. Кстати, у нас что, есть только 2 способа: текстовые файлы и RDBMS?

все же знают, что в unix есть команда join?

man join join - join lines of two files on a common field

Это безусловно верный путь. Но как же быть с многотерабайтными БД? Оно то конечно на 5 строчках в файле работает быстро. И тут я думаю проблема в мощности серверов, решение которой уничтожит все проблемы с производительностью.?

все же знают, что в unix есть команда join?

Есть и сорт и уник

Это безусловно верный путь. Но как же быть с многотерабайтными БД? Оно то конечно на 5 строчках в файле работает быстро. И тут я думаю проблема в мощности серверов, решение которой уничтожит все проблемы с производительностью.?

сильно зависит от паттерна использования. если там типичен seq scan по всему всегда, то можно так и оставить

сильно зависит от паттерна использования. если там типичен seq scan по всему всегда, то можно так и оставить

Именно, выключить и закапать ?

Это безусловно верный путь. Но как же быть с многотерабайтными БД? Оно то конечно на 5 строчках в файле работает быстро. И тут я думаю проблема в мощности серверов, решение которой уничтожит все проблемы с производительностью.?

А с чего Вы это вообще взяли? Если там только seq scan, эти вот "текстовые файлы" ещё и выиграют (и иногда, причём, намного)! ;)

А с чего Вы это вообще взяли? Если там только seq scan, эти вот "текстовые файлы" ещё и выиграют (и иногда, причём, намного)! ;)

А почему там только seq scan? Никакой фильтрации или поиска не происходит?

потому что, например, агрегация по меняющимся принципам

потому что, например, агрегация по меняющимся принципам

А как же умные алгоритмы индексации и кластеризации? Почему их не применяют?

это всё работает, когда ты знаешь, что ты с этими данными делать будешь

А почему там только seq scan? Никакой фильтрации или поиска не происходит?

Я написал "если". ;) Фильтрация —- запросто. Я больше скажу, некоторые "аналитические" БД (BIgQuery, например), у которых в основе —- всего лишь параллельный seqscan, могут, как говорится, "летать кругами" вокруг прочих (несмотря на их индексы и умные оптимизаторы).

Я написал "если". ;) Фильтрация —- запросто. Я больше скажу, некоторые "аналитические" БД (BIgQuery, например), у которых в основе —- всего лишь параллельный seqscan, могут, как говорится, "летать кругами" вокруг прочих (несмотря на их индексы и умные оптимизаторы).

и у них логарифмическое время выборки?

если ты не знаешь, как будет выглядеть твой завтрашний групбай, то тебе остаётся только секскан

Ситуация со seq scan оправдана только в одном случае, когда используется ленточный носитель данных. Да, там возможно паралельное чтение данных. но только в одном направлении.

и у них логарифмическое время выборки?

Нет, конечно. Но на практике-то результат очевиден. ;) И ещё, для некоторой сложной аналитики подходящих индексов либо совсем не бывает, либо придётся построить чуть ли не все возможные.

и у них логарифмическое время выборки?

а зачем логарифмическое, если N/ncpu тоже устраивает?

а зачем логарифмическое, если N/ncpu тоже устраивает?

Это сколько же надо ЦПУ на 1000 запросов в секунду? Вероятно 100?

откуда вы взяли 1000 запросов в секунду?

это как пример

их на таких данных в день примерно три

и то из-за опечатки в первых двух

если у тебя 1000 запросов, то ты знаешь, что у тебя делается с данными

Да, я думаю при seq scan тоже понятно что делается с данными

да, но как только он досчитается, все его индексы больше неактуальны

Сложная ситуация с расчетом OLAP кубов и других структур. Там действительно иногда приходяится индексировать каждое поле. Но как показывает практика, обычно все хотят агрегацию по определенному полю. Соответственно, возможно пересчитывать каждый раз не все вподряд, а только то, что требуется, те поля которые нужны.

И вместо того что-бы искать "очень" быстрые СУБД, возможно имеет смысл задуматься над структурой хранения данных?

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

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

Да, это повышает уровень сознания ?

А если серьезно, такая вещь как остовной граф (или остовное дерево) позволяет решить эту проблему

какую проблему, потерянный запрет поворота? или непрорисованное ребро? или неверное ограничение скорости? :)

хотя бы можно выявить те дуги графа которые явно имеют в себе некоректное значение

Сложная ситуация с расчетом OLAP кубов и других структур. Там действительно иногда приходяится индексировать каждое поле. Но как показывает практика, обычно все хотят агрегацию по определенному полю. Соответственно, возможно пересчитывать каждый раз не все вподряд, а только то, что требуется, те поля которые нужны.

А разве OLAP-кубы —- это сложная аналитика? Это же только предопределённые агрегаты и расчёты, правильно?

хотя бы можно выявить те дуги графа которые явно имеют в себе некоректное значение

явных тупизмов в нём нет, есть несоответствия реальности, которые нельзя выяснить никаким другим образом, кроме как сравнить с какими-то данными, из этой реальности пришедшими

А разве OLAP-кубы —- это сложная аналитика? Это же только предопределённые агрегаты и расчёты, правильно?

Сложность в том, что обычно строятся эти отчеты по всем данным. (Чаще конечно за период). И, как правильно было замечено, агрегаты могут менять свое значение. То есть приходится заново их пересчитывать.

OLAP - это просто, там ты знаешь, по чему у тебя будет групбай :)

Сложность в том, что обычно строятся эти отчеты по всем данным. (Чаще конечно за период). И, как правильно было замечено, агрегаты могут менять свое значение. То есть приходится заново их пересчитывать.

Да, приходится. Но _сложнее_ они от этого не становятся. :)

OLAP - это просто, там ты знаешь, по чему у тебя будет групбай :)

+1

Да, приходится. Но _сложнее_ они от этого не становятся. :)

Имеется ввиду сложность, точнее, стоимость расчета, а не сложность формирования OLAP

Имеется ввиду сложность, точнее, стоимость расчета, а не сложность формирования OLAP

Я имел в виду сложность самих аналитических запросов.

я прошу прощения, Npgsql не поддерживает именнованные параметры? типа у меня 100 параметров в функции с дефолтными значениями и чтобы передать один параметр туда, я должен и остальные тоже прописать???

http://www.mis3.local/getreport.php?_rep_code=null&_rep_id=61127916&DS_IDS=174833185&TYPE=LIS

http://www.mis3.local/getreport.php?_rep_code=null&_rep_id=61127916&DS_IDS=174833185&TYPE=LIS

Не удается получить доступ к сайту Не удалось найти IP-адрес сервера www.mis3.local. Выполните поиск по запросу mis3 local getreport в Google ERR_NAME_NOT_RESOLVED

это локальный веб сервер. прошу прощение в спешке не ту группу выбрал

Не удается получить доступ к сайту Не удалось найти IP-адрес сервера www.mis3.local. Выполните поиск по запросу mis3 local getreport в Google ERR_NAME_NOT_RESOLVED

Комрады, есть кто настраивал wal-e вместе с stole ?

я прошу прощения, Npgsql не поддерживает именнованные параметры? типа у меня 100 параметров в функции с дефолтными значениями и чтобы передать один параметр туда, я должен и остальные тоже прописать???

был неправ))

походу все же придётся накатывать pgbouncer поверх pgpool :(

а так всё хорошо начиналось

Мне тут сказали что pgsql плохое решение для не больших баз. Это правда?

это чушь

и она даже хрюкает...

всегда было интересно, на каком объеме заканчиваются маленькие БД и начинаются большие.

Мне тут сказали что pgsql плохое решение для не больших баз. Это правда?

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

"\dt" что показывает

Зачем аккаунт id варчар и 56?

Зачем аккаунт id варчар и 56?

Это уже другой вопрос

Ну и что вы хотите, у вас есть табличка users

О чем и говорит сообщение об ошибке.

О чем и говорит сообщение об ошибке.

я хочу, чтобы столбец в blobs ссылался на столбец в users. Значит, что она и должна существовать до того, как я создам blobs или я ошибаюсь?

Естественно.

Только вот если у вас users имеет иную структуру, чем вы хотите, то получится весьма занятно.

Только вот если у вас users имеет иную структуру, чем вы хотите, то получится весьма занятно.

Всё, разобрался. Спасибо большое за помощь

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

Обслуживать? Простите, это как?

Мне почудилось или кто-то пытался сделать реляцию с блобами?

Ох ща какой я булыжник закину в огород pgpool!!!

Эта сволота, занимает коннекты у PG и не отдаёт их!

Обслуживать? Простите, это как?

запускать и останавливать

Самое ржачное, когда у вас, к примеру, 2 pgpool в режиме watchdog

запускать и останавливать

не подсказывайте ;)

запускать и останавливать

А еще есть регламентные работы. Вотъ я какое страшное слово знаю!

даже не слово, а ругательство.

дооо...

а еще ему поди спирт требуется для протирки

так чё я врал то...

а! во!

а еще ему поди спирт требуется для протирки

Спирт требуется всегда! независимо от ...

вобщем когда у вас 2 pgpool в режиме watchdog, то операционный IP только на одном сервере конечно же.

Но если не дай Бог кто-то присоединится ко второму пулу

то он тут же отожрёт определенное количество коннектов на всех участниках пула ине отдаст их до перезапуска

Почему - вопрос пока не изучен.

всегда было интересно, на каком объеме заканчиваются маленькие БД и начинаются большие.

База считается большой, когда перестаёт полностью влезать в память:)

В какую?

всегда было интересно, на каком объеме заканчиваются маленькие БД и начинаются большие.

Для себя я выделил 3 размера таблиц (не бд). До 1 млн записей - с которыми даже без индексов можно, до 100 млн - индексы нужны - но все ещё несерьёзно и более 100млн - где уже надо думать над каждой операцией, задумываться о хранении и тп

Но это о сферическом коне в вакууме конечно

у меня вот под рукой таблица с точками от osm на 4 гига, в ней 168 278 885 записей и count(*) сексканом за 12 секунд делается

вроде больше 100млн

вроде небольшая

а в майисаме каунт мгновенный!

и по fdw?

если fdw умеет пушить count(*), то да!

если fdw умеет пушить count(*), то да!

не надо пушить - reltuples from pg_class или на худой конец tablesample system :)