Здравствуйте, slskor, Вы писали:
S>При insert на массивных вставках в Interbase бывает другая проблема. Описана здесь: http://www.ibase.ru/devinfo/oitoat.htm
Я весьма бегло просмотрел этот текст, поэтому позволю себе несколько замечаний, в которых в принципе не абсолютно уверен.
1. Не при "массивных вставках", а при "массивных вставках с промежуточными коммитами при наличии конкурирующих писателей".
2. Это проблема не insert-ов, но любого DML вообще.
3. Как я понял из общения с парнем, плотно занимающимся FB, выбор подходящего sweep-а и его настройка — это задача, примерно аналогичная настройке rollback segment-ов в Oracle (по сложности и влиянию на результат).
Здравствуйте, slskor, Вы писали:
S>Подчеркиваю, в оригинальном письме было "insert/update" написано.
Безусловно. Если уж хотите влететь и с update-ом — давайте про него.
S>И не надо переводить тему на более удобное для вас поле боя.
Итак — не затруднит ли Вас показать, где именно в задачах биллинга требуются "массовые update-ы", раз уж мы разобрались с insert-ами, и теперь только этим Вы обуславливаете непригодность FB для биллинга?
Наверное, стоит для начала определить, что есть "массовый" в контексте обсуждаемого вопроса. Насколько я понимаю, для этого операция должна быть регулярной и частой, во-вторых, нужно выбрать что-нибудь типа
— не менее N% от всех DML-операций по серверу в целом
— не менее N update-ов в рамках одной бизнес-функции
— не менее N конкурирующих пользователей, выполняющих по K апдейтов в рамках бизнес-функции
Здравствуйте, Softwarer, Вы писали:
S>Итак — не затруднит ли Вас показать, где именно в задачах биллинга требуются "массовые update-ы", раз уж мы разобрались с insert-ами, и теперь только этим Вы обуславливаете непригодность FB для биллинга?
То есть по-вашему биллинг — это только вставки? Было у меня как-то ТЗ на руках, в котором заказчик хотел 5 млн. операций вставки в день. Отчеты на несколько ближайших дней должны были быть детальными. Кроме того, должны были быть отчеты с аггрегированными данными за несколько лет в разных разрезах. Данная задача решаема только лишь на insert/select с приемлемой производительностью?
Здравствуйте, slskor, Вы писали:
S>То есть по-вашему биллинг — это только вставки?
Не перекладывайте на меня бремя доказательства. Вы выдвинули утверждение — Вы и доказывайте, что оно имеет место быть истинным. Обосновываете свою точку зрения массовыми апдейтами — значит, покажите, что они необходимы, причем именно массовые.
Например, пока что довольно забавно смотрится увязывание массовых апдейтов с расчетом агрегатов (такое впечатление, что Вы подразумеваете перерасчет агрегатов по каждому факту поступления новой записи).
S>Было у меня как-то ТЗ на руках,
Вполне нормальная постановка задачи, имхо.
S> Данная задача решаема только лишь на insert/select с приемлемой производительностью?
Прежде всего повторюсь, что бремя доказательства лежит на Вас.
Если Вы спрашиваете моего мнения, то "только лишь" — в смысле "ни одного апдейта нигде и никогда вообще" — не знаю, решаема или нет, но это извращение. Если же "без массовых апдейтов" — безусловно, решаема.
slskor wrote:
> S>Итак — не затруднит ли Вас показать, где именно в задачах биллинга > требуются "массовые update-ы", > Еще один пример: http://www.etracker.de > Попробуйте реализовать то же самое без аггрегирования данных, > поступающих в высоком темпе.
Лично делал подобное. Данные сначала складывались в очередь (сохраняемую
на диске в своем ОЧЕНЬ быстром формате), затем данные из этой очереди
затем скармливались системе правил, которая уже писала их в БД и делала
другие задачи.
При этом тоже был необходим real-time мониторинг некоторых потоков.
Решили очень просто — те потоки, которые в данный момент мониторились,
просто скармливались напрямую системе правил.
В качестве приятного дополнения была еще устойчивость к сбоям сервера БД.
Здравствуйте, slskor, Вы писали:
S>А я таки согласен, что Firebird плохо подходит для биллинга. Если не ошибаюсь, задачи биллинга подразумевают массированные вставки данных.
А я таки против Уже говорил, что биллинг бывает разный. Конкретики здесь насколько я помню никто особенной не приводил, разве, что... ОраЭкспресс разворачивается в гигабайт. От радость та какая... И тут возникает вопрос — откуда у "корпоративной" АТС на 100 номеров — массированные вставки данных?! А админы спят и видят, как бы все номера updat-ами перетосовать.
А такие маленькие программки которые пишут себе спокойно в Access (ох боже мой, ну почему не Firebird?!)... весьма находят применение.
Здравствуйте, Пацак, Вы писали:
П>Не вижу противоречий. Только не начинай опять старую песню "хочу моментально" — чудес не бывает.
Да что ж ты так любишь передергивать слова?
Говоришь, что не дельфинист...., но не "моментально", а "быстро". Нажимать ф5 руками меня ломает, для этого есть крон, а он не будет ждать, пока все удосужаться отвалиться от базы, а рубанет по живому. И результат получится не очень.
Ну и, конечно, множество недотатков у длинных транзакций уже описано выше. И, раз уж инстумент позволяет пользовать всю сессию в одной транзакции, причем гораздо проще, чем в нескольких, то народ так и будет реализовывать.
Здравствуйте, OLEGus1, Вы писали:
OLE>Говоришь, что не дельфинист...., но не "моментально", а "быстро". Нажимать ф5 руками меня ломает, для этого есть крон, а он не будет ждать, пока все удосужаться отвалиться от базы, а рубанет по живому. И результат получится не очень.
Если по крону, то какая тебе нафиг разница — "быстро" или "медленно"? Как срабатывал он, скажем, раз в сутки — так и будет срабатывать, как сохранял данные на момент своего старта — так и будет сохранять. Или тут вопрос религиозный?
OLE>Ну и, конечно, множество недотатков у длинных транзакций уже описано выше.
... и там же выше выянилось, что для insert они неактуальны. А необходимость в биллинге постоянных массовых длинных апдейтов АФАИР так и не аргументировали.
OLE>И, раз уж инстумент позволяет пользовать всю сессию в одной транзакции, причем гораздо проще, чем в нескольких, то народ так и будет реализовывать.
Давай ты будешь говорить не за всех, а за себя? Обсуждается не наличие возможности написать прогу криво, а отсутствие возможности написать ее прямо. Тебя кто-то заставляет в биллинге делать commit_retaining и держать сессию постоянно открытой? Или "мыши плакали, кололись, но продолжали жрать кактус"? И не говори, что ты один умный и этого делать не будешь, а окружающие все дураки, так и мечтающие наступить на грабли.
Слова, пустые слова, подумал Стормгрен. Слова, за которые прежде люди дрались и умирали, но никогда больше не станут за них ни умирать, ни драться. И от этого мир станет лучше.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Horror_Infinity, Вы писали:
H_I>> Тот же Oracle Express ставится полностью минут за 15. M>Но не везде.. M>Кстати, инсталлятор там все еще явовский? Вот уж за что поубивав-бы...
Чем явовский инсталлер-то не угодил? Не тормознутее(и гораздо менее глючный), чем ms installer. Да и не уйдут они от него — он один на все оси, а иначе для каждой свой писать надо...
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Уже говорил, что биллинг бывает разный. Конкретики здесь насколько я помню никто особенной не приводил, разве, что... ОраЭкспресс разворачивается в гигабайт. 
От радость та какая... И тут возникает вопрос — откуда у "корпоративной" АТС на 100 номеров — массированные вставки данных?! А админы спят и видят, как бы все номера updat-ами перетосовать. 
Играет silent 
