В общем, чтобы сконвертировать все данные из старой системы, скормить новой, запуститься на трёх серверах сразу — 3 часа.
А что мешало перед запуском пристроиться в хвост работающей системы — научиться обрабатывать её трафик, спокойно, без спешки, инициализироваться и поддерживать актуальность данных до включения рубильника?
Здесь может показаться что Петя очень не справедлив к Васе. Но с другой стороны Петя ведь нес финансовые риски, если бы Вася не дал результата, Петя в течении десяти лет отдавал бы Васе тыщубаксов по чем зря. И сколько таких Вась работает на Петю не принося результата только Пете ведомо. Может так статься, что полученный Петей триллион и не отобъет всех его расходов.
Лучше — чем? Тем, что появляется еще одно звено системы — выделенный сервер, который нужно ставить на мониторинг, поддерживать, воспроизводить на тестовых окружениях, учитывать при планировании переездов? Да, идея организации репортинга на стороне СУБД сомнительна. Но если это затевается для одного, двух, пяти отчетов лишь — идея выделения под то обособленного звена тоже вылядит как бы не совсем блестяще.
Однако вы ответили не совсем на мой вопрос. Я спросил чем, с вашей точки зрения, плохо сохранять исходный код жава процедуры в схеме данных. Вы ответили тем, что плохо делать репортинг средствами жава хп, это чуть-чуть о другом.
Если ява испльзуется для мелких утилитарных функций, намного лучше исходный код сохранить в СУБД, нежели заетвать репозиторий для хранения кода трех, пяти, десяти классов, обеспечивать согласованность исходного кода с исполняемомым, и всякий раз чесать репу при переносах на новое железо/новую платформу.
Они ж пустили P2P сервер на Аллодах. Думаю, это можно рассматривать либо как сегментацию, либо как пилот этой модели распространения. Исходя из того, что на закате многих проектов наоборот происходит миграция с модели p2p на f2p, заключаю, что скорее второе — т.е. пилот. Соответственно про результатам пилота, скорее всего, и будет принято решение. И повлиять на это решение можно самостоятельно, оформив подписку ))
Что же касается требований состоятельности для возможности играть в Аллоды — сейчас это уже миф, порожденный «эхом войны». Когда-то — да, были времена, когда за реал в игре можно было купить очень значительное игровое преимущество, но, уверяю вас, и тогда вполне можно было получать колоссальное удовольствие от игры не особо при том обременяя себя затратами. С тех пор Аллодс тим многому научились, требования доната стали куда мягче, а прежние имба плюшки нивелировались уже несколькими апами каплевела. В принципе, у меня есть все основания полагать, что в Аллодс тим вполне разумные люди работают, которые определенно понимают, что испачкаться куда проще чем отмыться и вряд ли станут наступать на прежние грабли в новом проекте. Остается лишь пожелать им поменьше креативных «залетных», «искушенных» в маркетинге, да с привилегиями принимать решения.
но на практике агрегатные таблицы состоят более, чем из одной строчки
Пусть и более чем из одной, как бы то ни было, гранулярность блокировки при преаггрегации возрастает и возрастает во столько раз, сколько строк мы схлопываем в одну группу. Это могут быть и порядки и порядки порядков.
А за длинные пишущие транзакции пальчики надо кусачками… или молоточком…
Зря вы столь категоричны. Очень зря )
PG версионник — да. Он не блокирует запись чтением и чтение записью… Но запись ведь блокирует запись все равно — так? Или как вы себе это представляете?
как вставка может надолго кого-то заблокировать — я себе слабо представляю
я вам расскажу.
Возьмем гипертрофированный пример — тот самый, который использует автор статьи. Он считает сумму по ВСЕЙ таблице. Т.е. предложенная вами таблица преаггрегации будет содержать только одну строчку. Соответственно все инсерты в целевую таблицу посредством предложенного вами триггера, будут апдейтить одну эту самую строчку, соответственно все эти апдейты аккуратненько выстроятся в очредь по блокировке на записи. Весь параллелизм упорядочится. А если с целевой таблицей работают пользователи и приложение используют длинные транзакции, все прочие вставки в эту таблицу будут ожидать пока МарИванна допьет свой кофей.
Надеюсь, я не открою большой секрет, обратив внимание на то, что если выполнять преаггрегацию при изменении/обновлении, надо очень, очень внимательно отнестись к стратегии блокирования, ибо все может прочно встать колом на дедлоках при многопоточной вставке/модификации исходных данных. И даже если удастся грамотно раскидать блокировки, параллельный процесс модификации данных вполне может деградировать в последовательный.
Преаггрегация возможна скорее в частном случае, нежели в общем, и к ней должны быть определенные предпосылки.
При добавлении в середину таблицы точно так же произойдёт разделение заполненной страницы пополам и в одну из этих половинок добавятся новые данные и получим в середине данных две наполовину заполненные страницы, остальные страницы никакого действия над собой не увидят
Я так понимаю, что такое действие возможно, лишь если сосдение листья имеют кроссылки друг на друга. Получается как бы двусвязный список, добавление в середину которого не приводит к переупорядочиванию хвоста списка.
В документации же по mySQL мной лично не найдено ни одной строчки, оставляющей надежду, что дела там обстоят именно так. Более того, там не однократно упоминается физическое упорядочивание. К рассуждениям какие следствия от того могут иметь место быть в результате такой реализации, и как оно вобще может при этом как-то работать, вы и оставлили свой коментарий ))
У меня отец тоже из энергетики и тоже часто жаловался, что не раз ему поручали выводить людей в выходные и праздники только лишь для того, чтобы в понедельник отчитаться «Мы сделали все что могли, но законы Кирхгофа, как и предполагалось, нарушить так и не смогли».
>>не знаю даже, почему)
хм… тоже не знаю… возможно при max(pk_id) просто берется с хвоста индекса. Т.е. де факто отрабатывает запрос select id from table order by id desc limit 1. Было бы интересно, если бы это было действительно так.
А что мешало перед запуском пристроиться в хвост работающей системы — научиться обрабатывать её трафик, спокойно, без спешки, инициализироваться и поддерживать актуальность данных до включения рубильника?
Понял, спасибо.
Однако вы ответили не совсем на мой вопрос. Я спросил чем, с вашей точки зрения, плохо сохранять исходный код жава процедуры в схеме данных. Вы ответили тем, что плохо делать репортинг средствами жава хп, это чуть-чуть о другом.
Если ява испльзуется для мелких утилитарных функций, намного лучше исходный код сохранить в СУБД, нежели заетвать репозиторий для хранения кода трех, пяти, десяти классов, обеспечивать согласованность исходного кода с исполняемомым, и всякий раз чесать репу при переносах на новое железо/новую платформу.
Что же касается требований состоятельности для возможности играть в Аллоды — сейчас это уже миф, порожденный «эхом войны». Когда-то — да, были времена, когда за реал в игре можно было купить очень значительное игровое преимущество, но, уверяю вас, и тогда вполне можно было получать колоссальное удовольствие от игры не особо при том обременяя себя затратами. С тех пор Аллодс тим многому научились, требования доната стали куда мягче, а прежние имба плюшки нивелировались уже несколькими апами каплевела. В принципе, у меня есть все основания полагать, что в Аллодс тим вполне разумные люди работают, которые определенно понимают, что испачкаться куда проще чем отмыться и вряд ли станут наступать на прежние грабли в новом проекте. Остается лишь пожелать им поменьше креативных «залетных», «искушенных» в маркетинге, да с привилегиями принимать решения.
А можете на ушко шепнуть когда ждать Skyforge и стоит ли его ждать?
Пусть и более чем из одной, как бы то ни было, гранулярность блокировки при преаггрегации возрастает и возрастает во столько раз, сколько строк мы схлопываем в одну группу. Это могут быть и порядки и порядки порядков.
А за длинные пишущие транзакции пальчики надо кусачками… или молоточком…
Зря вы столь категоричны. Очень зря )
как вставка может надолго кого-то заблокировать — я себе слабо представляю
я вам расскажу.
Возьмем гипертрофированный пример — тот самый, который использует автор статьи. Он считает сумму по ВСЕЙ таблице. Т.е. предложенная вами таблица преаггрегации будет содержать только одну строчку. Соответственно все инсерты в целевую таблицу посредством предложенного вами триггера, будут апдейтить одну эту самую строчку, соответственно все эти апдейты аккуратненько выстроятся в очредь по блокировке на записи. Весь параллелизм упорядочится. А если с целевой таблицей работают пользователи и приложение используют длинные транзакции, все прочие вставки в эту таблицу будут ожидать пока МарИванна допьет свой кофей.
Преаггрегация возможна скорее в частном случае, нежели в общем, и к ней должны быть определенные предпосылки.
Я так понимаю, что такое действие возможно, лишь если сосдение листья имеют кроссылки друг на друга. Получается как бы двусвязный список, добавление в середину которого не приводит к переупорядочиванию хвоста списка.
В документации же по mySQL мной лично не найдено ни одной строчки, оставляющей надежду, что дела там обстоят именно так. Более того, там не однократно упоминается физическое упорядочивание. К рассуждениям какие следствия от того могут иметь место быть в результате такой реализации, и как оно вобще может при этом как-то работать, вы и оставлили свой коментарий ))
хм… тоже не знаю… возможно при max(pk_id) просто берется с хвоста индекса. Т.е. де факто отрабатывает запрос select id from table order by id desc limit 1. Было бы интересно, если бы это было действительно так.