Книга отличная. Не уверен, что когда-нибудь буду фрилансером, но такая замечательная работа достойна поддержки. Электронную версию купил, если будет бумага с возможностью получить автограф автора – тоже обязательно куплю. Хотя, конечно, бумага – это про пять минут славы, а не про заработок :)
Так оно для этой задачи и придумано. Сравниваем хеши для двух таблиц. Если совпало - хорошо, если нет - переходим к сравнению хешей предыдущего уровня. В конце концов дойдём до маленького диапазонв, где скрыты расхождения.
О, Астра – замечательная компания. У них на сайте минимум полгода висит вакансия. Я послал им запрос, но они не ответили даже «спасибо, мы с вами может быть свяжемся».
Ну тогда и PostgreSQL не надо рассматривать – а вдруг?
Так-то Tarantool выпущен под BSD-лицензией, и всё, что надо некорпоративному пользователю, там есть. Мало того, vk – не единственная компания, предлагающая поддержку Тарантула.
Более того, для сетевого ввода это тоже может быть верно.
Пример – чтение таблицы целиком из PostgreSQL (SELECT * FROM <TABLE>) в Perl при помощи fetchall_arrayref. Если просто читать данные, то память под массив с результатом выделяется один раз, и чтение занимает примерно Х времени. А если попытаться эти данные обрабатывать, передавая полученный массив аргументом в какую-нибудь функцию, то уже 5×Х
«Только на insert» и только на больших объёмах работает не мой пункт, а тот подход, который, скорее всего, применён в эксперименте, на который вы ссылаетесь.
А какже такие замечательные bulk конструкции Oracle (для всех DML как FORALL)?
Что «как же»? Всё с этими инструкциями хорошо, они прекрасно работают. Это именно bulk, а не dpl.
Дело в том, что SQL и PL/SQL изолированы друг от друга и общаются через интерфейс – точно так же, как Java-приложение с SQL. Forall – это один вызов, который принимает в качестве параметра массив. За один вызов выполняется столько операций, сколько элементов в массиве. Насколько я понимаю, «банальный батчинг» в JDBC работает так же.
сли хочешь найти хорошее архитектурное решение по реляционной СУБД , лучше сначала в Oracle посмотреть
Пожалуй, соглашусь.
Несколько лет назад я был на встрече с Томом Кайтом. Его спросили: если бы вы вернулись в далёкие 80-е с теми знаниями, что у вас есть сейчас, что бы вы изменили в архитектуре Oracle? Он ответил: да глобально – наверное, ничего...
Снижать нагрузку бессмысленно. Редкие коммиты помогают тогда, когда узким местом является именно запись в журнал транзакций. Я ж говорил, на плохих дисках разница была действительно в разы.
In SQL Server 2019, up to eight Log Writer threads were added
Есть нюанс. Все транзакции, выполненные в одной базе, должны быть записаны в журнал строго последовательно, поэтому добавление писателей на пропускную способность базы не влияет вообще никак – работает только один.
Уникальность MS SQL Server в том, что у него в каждой базе данных свой журнал (у Oracle, PostgreSQL и DB2 – один журнал на экземпляр, т. е. на все базы, обслуживаемые экземпляром). То есть добавление потоков может увеличить пропускную способность экземпляра, но не базы.
Я, как вы заметили, не специалист по конкретно SQL Server, поэтому не могу в полной мере оценить результат по ссылке. За Oracle скажу, что там есть Bulk (т. е. когда у команды аргумент-массив) и direct-path load (когда данные пишутся вообще в обход всех механизмов – клиент формирует готовые блоки данных и записывает их в таблицу выше highwatermark). Я не раз встречал, что инструменты пишут слово «bulk», но при этом используют DPL. И вот у него с традиционной загрузкой действительно примерно такая разница, как в эксперименте, на который вы ссылаетесь. Но это только insert (update так не работает) и только очень массивный (для группировки транзакций этот метод не годится).
Всё зависит от конфигурации дисковой подсистемы. Конкретно в этой конфигурации ускорения не будет, т. к. проблема исключительно в процессоре. А вот на медленных дисках (когда вместо ssd были обычные hdd) ускорение было примерно в пять раз.
Именно так. Даже журнальный буфер держится в памяти. Конечно, когда он заполняется, сервер сбрасывает его на диск, но это делается асинхронно. То есть когда вы получили управление обратно от «маленькой DML», журнальная информация сохранена в памяти, но совсем не обязательно сохранена на диске.
режим snapshot появился сравнительно недавно
Примерно лет пятнадцать как. Пора бы включить.
Типа не волнуйтесь если у вас много мелких dml просто облачите это в одну транзакцию побольше?
Именно это я и хочу сказать.
Разумеется, одна bulk-операция будет быстрее, чем много маленьких, но ускорение составит десятки если не единицы процентов. Для того, чтобы ускорить обработку транзакций, надо в порядке убывания эффекта
Уменьшить количество транзакций. То есть вся бизнес-транзакция должна помещаться в одну транзакцию БД, никаких промежуточных commit’ов
Использовать подготовленные запросы (prepared queries). Для Oracle это даёт фантастический эффект, для PostgreSQL – просто огромный.
Избавиться от блокировки select’ов (в Oracle и PostgreSQL MVCC включен по умолчанию и не выключается, а вот в MS SQL, оказывается, до сих пор надо включать)
И только на четвёртом месте – замена множества «маленьких DML» на bulk-операции.
Буквально на днях проводил нагрузочный тест на PostgreSQL. 4 ядра, SSD, исключительно мелкие DML, в одной транзакции – два insert и два update. Около 3000 транзакций в секунду, узкое место – процессорная мощность.
У вас в одном комментарии столько ошибок, что я, кажется, понимаю, почему 1С с базой работает вот так. Наверно, там все «специалисты» по БД не имеют представления об её устройстве.
Transaction log как раз существует чтобы иметь возможность откатить транзакцию
log существует для того, чтобы накатить транзакцию после сбоя экземпляра. В нормальных ситуациях никто никогда этот лог не читает (разумеется, кроме репликации). Для отката существует «сегмент отката», только вот называется он в разных БД по-разному. В Oracle – undo space, в PostgreSQL новые значения вообще пишутся рядом со старыми, а старые затираются только вакуумом, а в MS SQL, если мне память не изменяет, «сегмент отката» размещается в базе данных tempdb
И commit всего лишь одно из условий Flush на диск
Нет. При commit обязательно идёт flush на диск, если только это не тестовая база, где можно безнаказанно терять данные. Сбрасывается только журнальный буфер, но не сами блоки с данными.
Есть такое понятие check point
Есть такое понятие, но вы сначала разберитесь, что оно означает. Это сброс на диск изменённых блоков данных, и он действительно идёт асинхронно. Сигналом к нему является не commit, а одно из двух событий – превышение порога количества изменённых блоков в кеше или переключение файла в журнале транзакций.
Количество записей зависит не от количества операций, а от количества commit’ов, то есть от количества транзакций. Хотя, конечно, если везде ставить по умолчанию autocommit (руки б пообрывать тому_кто), то эти цифры равны :)
Книга отличная. Не уверен, что когда-нибудь буду фрилансером, но такая замечательная работа достойна поддержки. Электронную версию купил, если будет бумага с возможностью получить автограф автора – тоже обязательно куплю. Хотя, конечно, бумага – это про пять минут славы, а не про заработок :)
Ага.
Александр Матлин, "О вредности устного счёта"
Не надо хранить, можно считать каждый раз. Это точно быстрее, чем переписывать данные в spark.
Так оно для этой задачи и придумано. Сравниваем хеши для двух таблиц. Если совпало - хорошо, если нет - переходим к сравнению хешей предыдущего уровня. В конце концов дойдём до маленького диапазонв, где скрыты расхождения.
О, Астра – замечательная компания. У них на сайте минимум полгода висит вакансия. Я послал им запрос, но они не ответили даже «спасибо, мы с вами может быть свяжемся».
Успехов им в поиске сотрудников с таким подходом.
Ну тогда и PostgreSQL не надо рассматривать – а вдруг?
Так-то Tarantool выпущен под BSD-лицензией, и всё, что надо некорпоративному пользователю, там есть. Мало того, vk – не единственная компания, предлагающая поддержку Тарантула.
Как говорил Артемий Лебедев, «пусть они себе жён по 44-ФЗ ищут».
Присоединяюсь к этому пожеланию.
Как говорится, +1
Более того, для сетевого ввода это тоже может быть верно.
Пример – чтение таблицы целиком из PostgreSQL (SELECT * FROM <TABLE>) в Perl при помощи fetchall_arrayref. Если просто читать данные, то память под массив с результатом выделяется один раз, и чтение занимает примерно Х времени. А если попытаться эти данные обрабатывать, передавая полученный массив аргументом в какую-нибудь функцию, то уже 5×Х
Джойны на спарке? Жесть какая.
А про дерево Меркла вы когда-нибудь слышали?
Ссылка «отписаться» решает проблему.
Я, например, некоторые рассылки читаю с удовольствием.
«Только на insert» и только на больших объёмах работает не мой пункт, а тот подход, который, скорее всего, применён в эксперименте, на который вы ссылаетесь.
Что «как же»? Всё с этими инструкциями хорошо, они прекрасно работают. Это именно bulk, а не dpl.
Дело в том, что SQL и PL/SQL изолированы друг от друга и общаются через интерфейс – точно так же, как Java-приложение с SQL. Forall – это один вызов, который принимает в качестве параметра массив. За один вызов выполняется столько операций, сколько элементов в массиве. Насколько я понимаю, «банальный батчинг» в JDBC работает так же.
Пожалуй, соглашусь.
Несколько лет назад я был на встрече с Томом Кайтом. Его спросили: если бы вы вернулись в далёкие 80-е с теми знаниями, что у вас есть сейчас, что бы вы изменили в архитектуре Oracle? Он ответил: да глобально – наверное, ничего...
Снижать нагрузку бессмысленно. Редкие коммиты помогают тогда, когда узким местом является именно запись в журнал транзакций. Я ж говорил, на плохих дисках разница была действительно в разы.
Есть нюанс. Все транзакции, выполненные в одной базе, должны быть записаны в журнал строго последовательно, поэтому добавление писателей на пропускную способность базы не влияет вообще никак – работает только один.
Уникальность MS SQL Server в том, что у него в каждой базе данных свой журнал (у Oracle, PostgreSQL и DB2 – один журнал на экземпляр, т. е. на все базы, обслуживаемые экземпляром). То есть добавление потоков может увеличить пропускную способность экземпляра, но не базы.
Я, как вы заметили, не специалист по конкретно SQL Server, поэтому не могу в полной мере оценить результат по ссылке. За Oracle скажу, что там есть Bulk (т. е. когда у команды аргумент-массив) и direct-path load (когда данные пишутся вообще в обход всех механизмов – клиент формирует готовые блоки данных и записывает их в таблицу выше highwatermark). Я не раз встречал, что инструменты пишут слово «bulk», но при этом используют DPL. И вот у него с традиционной загрузкой действительно примерно такая разница, как в эксперименте, на который вы ссылаетесь. Но это только insert (update так не работает) и только очень массивный (для группировки транзакций этот метод не годится).
Производится, конечно. Но топик-то – о повышении производительности!
Всё зависит от конфигурации дисковой подсистемы. Конкретно в этой конфигурации ускорения не будет, т. к. проблема исключительно в процессоре. А вот на медленных дисках (когда вместо ssd были обычные hdd) ускорение было примерно в пять раз.
Все операции фиксируются в ЖУРНАЛЬНОМ БУФЕРЕ. А на диск содержимое буфера сбрасывается асинхронно. Клиент ждёт сброса буфера только при commit’е.
Операция добавления данных в буфер в памяти едва ли когда-нибудь станет узким местом. А вот операция записи в файл – таки да.
Именно так. Даже журнальный буфер держится в памяти. Конечно, когда он заполняется, сервер сбрасывает его на диск, но это делается асинхронно. То есть когда вы получили управление обратно от «маленькой DML», журнальная информация сохранена в памяти, но совсем не обязательно сохранена на диске.
Примерно лет пятнадцать как. Пора бы включить.
Именно это я и хочу сказать.
Разумеется, одна bulk-операция будет быстрее, чем много маленьких, но ускорение составит десятки если не единицы процентов. Для того, чтобы ускорить обработку транзакций, надо в порядке убывания эффекта
Уменьшить количество транзакций. То есть вся бизнес-транзакция должна помещаться в одну транзакцию БД, никаких промежуточных commit’ов
Использовать подготовленные запросы (prepared queries). Для Oracle это даёт фантастический эффект, для PostgreSQL – просто огромный.
Избавиться от блокировки select’ов (в Oracle и PostgreSQL MVCC включен по умолчанию и не выключается, а вот в MS SQL, оказывается, до сих пор надо включать)
И только на четвёртом месте – замена множества «маленьких DML» на bulk-операции.
Буквально на днях проводил нагрузочный тест на PostgreSQL. 4 ядра, SSD, исключительно мелкие DML, в одной транзакции – два insert и два update. Около 3000 транзакций в секунду, узкое место – процессорная мощность.
У вас в одном комментарии столько ошибок, что я, кажется, понимаю, почему 1С с базой работает вот так. Наверно, там все «специалисты» по БД не имеют представления об её устройстве.
log существует для того, чтобы накатить транзакцию после сбоя экземпляра. В нормальных ситуациях никто никогда этот лог не читает (разумеется, кроме репликации). Для отката существует «сегмент отката», только вот называется он в разных БД по-разному. В Oracle – undo space, в PostgreSQL новые значения вообще пишутся рядом со старыми, а старые затираются только вакуумом, а в MS SQL, если мне память не изменяет, «сегмент отката» размещается в базе данных tempdb
Нет. При commit обязательно идёт flush на диск, если только это не тестовая база, где можно безнаказанно терять данные. Сбрасывается только журнальный буфер, но не сами блоки с данными.
Есть такое понятие, но вы сначала разберитесь, что оно означает. Это сброс на диск изменённых блоков данных, и он действительно идёт асинхронно. Сигналом к нему является не commit, а одно из двух событий – превышение порога количества изменённых блоков в кеше или переключение файла в журнале транзакций.
Это как? Про то, что транзакция ≠ команда, теперь не рассказывают?
Количество записей зависит не от количества операций, а от количества commit’ов, то есть от количества транзакций. Хотя, конечно, если везде ставить по умолчанию autocommit (руки б пообрывать тому_кто), то эти цифры равны :)