а еще настроенный автовакуум слетает, когда изменяется нагрузка на БД. Настроил ты его на один показатель, таблицы выроста в 10 раз — и все, он уже не будет справляться — его постоянно нужно отслеживать и крутить — я считаю это проблемой. В том же MySQL один раз выставили на большой объем данных — и забыли. Так что, у каждого свои тараканы под кроватью.
В оракле (и в mysql InnoDB) тоже есть UNDO логи, которые как-то там чистятся.
Воот, они как-то там чистятся, и я уверен, что разработчики об этом подумали и сделали эту чистку максимально производительно. Не вижу ничего, чтобы мешало PG чистить такие данные при коммите транзакции. Везде всегда говорят — настраивайте автовакуум агрессивнее, но что может быть агрессивнее, чем чистить сразу за собой?
это все я знаю, но это уже следствие такой архитектуры, это все уже мануалы аля «FAQ как обойти наш костыль»
я как-то лично спрашивал того же Илью Космодемьянского, упоминавшегося выше, зачем такой механизм с мертвыми кортежами, ведь от него только одна головная боль с этими автовакуумами — он просто пожал плечами — «мол, такая архитектура»
Проблема тут скорее архитектурная. Добрые молодцы в PostgreSQL придумали версионность через неизменение старых картежей, а разгребать последствия предлагают пользователю через костыль — автовакуум. Почему нельзя было скрыть механизм чистки старых кортежей? хз
если таблицы у вас до 10к строк и вялое изменение данных — ок, из коробки автовакуум работает.
Но если размер больше или нагрузка выше — автовакуум может висеть минутами, блокируя полный доступ к таблице. Если много транспортных таблиц — то самого кол-ва потоков автовакуума может не хватать (пока 3 дефолтных чистят 3 таблицы — еще 6 уже забились) Причем это сложно отловить — в коде выполняется очень простые SQL — все должно «летать». Но периодически система «подвисает». Идем в базу — select * from db_activity — а там висят… «богатыри»… молотят.
Работал и с тем и с другим довольно плотно.
Везде свои плюсы и минусы.
В MySQL напрягали очень долгие DDL команды на больших таблицах (до версии 5.5, хз как сейчас). В PG напрягает архитектура UPDATE=DELETE+INSERT, отсюда куча внутреннего бекграунда, который на вас «выливают» и просят сконфигурить для себя (автовакуум, пухнущие индексы).
не, я не про социализацию.
— сайт с аудио-гидами по городам по прежнему будет принадлежать вам — контент платный, подбирается и составляется вами (не лично конечно, но качество его всегда можно будет проверить).
— устройство будет заточено не только под ваш аудио-гид, но будет выступать как платформа по воспроизведению формата связки «GPS-аудио», соответственно спрос по всему миру
— даст толчек для альтернативных компаний разработывать свои аудио-гиды по своим городам, ведь сама идея классная, в музеях уже активно используется такая идея.
я, как обычный пользователь, лучше бы купил такое устройство 1 раз и ездил бы с ним по миру, чем брал бы его на прокат каждый раз. Мое ИМХО конечно.
Повторюсь, мониторить ВСЕ новости в реальном времени НЕРЕАЛЬНО. Новость ЕСТЬ в твиттере спустя 5-10 мин. Как вы ее найдете — Ваша проблема (уникальный поиск в реальном времени по миллиарду твитов Вам в помощь).
Нет, новость о случае в Питерском метро я узнал до официальных СМИ. Представьте ситуацию — происходит взрыв. Чтобы репортеры о нем узнали им должен кто-то позвонить. Ну а если этот кто-то имеет твиттер на телефоне, что ему стоит сделать снимок и тут же затвиттить картинку с небольшим описанием? И в итоге 140 символов быстрее набрать, чем статью. Эта новость уже в есть триттере, а репортеры только собираются выехать. Каждый становится репортером.
Поиск в реальном времени по миллиарду твиттов вам в помощь. Причем вед-морда даже обновляет результаты поиска каждые 5-10 сек, т.е. можно написать запрос и ждать.
Воот, они как-то там чистятся, и я уверен, что разработчики об этом подумали и сделали эту чистку максимально производительно. Не вижу ничего, чтобы мешало PG чистить такие данные при коммите транзакции. Везде всегда говорят — настраивайте автовакуум агрессивнее, но что может быть агрессивнее, чем чистить сразу за собой?
я как-то лично спрашивал того же Илью Космодемьянского, упоминавшегося выше, зачем такой механизм с мертвыми кортежами, ведь от него только одна головная боль с этими автовакуумами — он просто пожал плечами — «мол, такая архитектура»
если таблицы у вас до 10к строк и вялое изменение данных — ок, из коробки автовакуум работает.
Но если размер больше или нагрузка выше — автовакуум может висеть минутами, блокируя полный доступ к таблице. Если много транспортных таблиц — то самого кол-ва потоков автовакуума может не хватать (пока 3 дефолтных чистят 3 таблицы — еще 6 уже забились) Причем это сложно отловить — в коде выполняется очень простые SQL — все должно «летать». Но периодически система «подвисает». Идем в базу — select * from db_activity — а там висят… «богатыри»… молотят.
Везде свои плюсы и минусы.
В MySQL напрягали очень долгие DDL команды на больших таблицах (до версии 5.5, хз как сейчас). В PG напрягает архитектура UPDATE=DELETE+INSERT, отсюда куча внутреннего бекграунда, который на вас «выливают» и просят сконфигурить для себя (автовакуум, пухнущие индексы).
Поясню на нашем конкретном примере. В нашем случае проверяются 3 показателя системы — скорость обработки карт ©, скорость обработки товаров(T) и запаздывание чеков более, чем на 5 минут(P). Далее, каждый прогон (F(x) выдает конкретные цифры этих показателей(C_real,T_real,P_real), сравнивая их с бизнес требованиями для этих показателей (C_expect,T_expect,R_expect) получим числовой результат прогона.
Т.е. что-то вроде F(x)= min(C_real/C_expect*100,T_real/T_expect*100,P_real/P_expect*100) — наихудший показатель в процентром соотношении
это и есть результат. Сейчас созданный стенд дал нам возможность следить за этим результатом. Можно посмотреть как железо или настройки меняют этот результат. Ну а далее, мы будем увеличивать число параметров, по которым считается результат прогона.
Как?
Ведь цвета вы не видите и приятного сочетания тоже. Вот ваш пример обесцвеченый, как вы поняли, что его сочетание приятное?
— сайт с аудио-гидами по городам по прежнему будет принадлежать вам — контент платный, подбирается и составляется вами (не лично конечно, но качество его всегда можно будет проверить).
— устройство будет заточено не только под ваш аудио-гид, но будет выступать как платформа по воспроизведению формата связки «GPS-аудио», соответственно спрос по всему миру
— даст толчек для альтернативных компаний разработывать свои аудио-гиды по своим городам, ведь сама идея классная, в музеях уже активно используется такая идея.
я, как обычный пользователь, лучше бы купил такое устройство 1 раз и ездил бы с ним по миру, чем брал бы его на прокат каждый раз. Мое ИМХО конечно.