Коваленко Дмитрий,

imho фигня полная. я даже не знаю, что комментировать.

Коваленко Дмитрий,

все-таки комментарий появился. а с какого боку тут мульти-тредовое приложение? Тест про вставку из параллельных коннектов.
Кроме того, один коннект в ФБ что 2.5 что 3.0 не распараллеливается. А я у тебя что-то там вставки в N коннектах совсем не вижу. Может я код C# не понимаю, но тем не менее.
Отсюда вывод, что результаты тем более ахинейные, и ты просто меряешь распараллеливаемость своего OLE DB провайдера.

Romanzek,

ткните меня носом в код. В любом случае, я уже такое количество тестов проводил, что нутром чую, что тест должен быть максимально чистым. В нашем случае мы стартовали isql с входным скриптом insert. Что может быть чище? Никакого оверхеда на компоненты, worker threads, и так далее.

Кроме того, результаты. в 20 потоках 1млн записей вставляется в 4 раза быстрее, чем в 1. Это при том, что все эти потоки лупят в одну таблицу. Где тут распараллеливаемость может "вдруг случиться", скажите мне?
Каким образом 32 isql втыкают записи на супере, на 12-ядерном проце так же, как в 1 коннекте, и каким образом 20 тредов из одного приложения втыкают этот же миллион записей в 4 раза быстрее чем 1 коннект? Откуда может быть такая разница?
Ну давайте, объясните мне.

hvladА у Коваленко препарированные инсерты. Ы ? :)
Или ты set bulk_insert умеешь готовить ? :)
ну и нахрена это надо? я не очень понимаю смысл такого теста. Ну фиг с ним, пусть препарированные. Но пусть запускает N процессов тогда. Не надо вот этой псевдо-многопоточности в C#.

hvladА ещё у него таблица всего с одним полем (индекс есть)
у нас в тесте было



Что с одним, что с двумя столбцами - это напороться на артефакт с 50% заполнением страниц. Я про это уже несколько раз писал. Правда, на ФБ 3 не проверял.

господа. Для повтора теста требуется некий консенсус по поводу условий этого теста.
Если я еще понимаю
1. проверку вставки без индексов совсем
хотя это нереальный случай, то
2. проверка вставки с несколькими индексами
относится несколько к другому тесту - а именно - замедлению вставки при увеличении количества индексов.
Понятно, что к тесту как таковой параллельной вставки это имеет мало отношения. У нас уже были семинары (за рубежом и в Москве) где Алексей Ковязин показывал разницу между вставкой с индексом bigint и индексом varchar(36).
То есть, понятно, что вставка с увеличением количества индексов замедлится, и ее можно было бы проверить в монопольном режиме, достаточно быстро, а дальше уже экстраполировать на результаты "минимальной" вставки в отношении "многопользовательского режима".

Но - вы чего хотите-то? Например, у нас в кулуарах зашел вопрос об использовании gen_id. Например, если его вообще исключить, то получится сугубо синтетический тест. С другой стороны, вызов gen_id на каждый insert "монополизирует" вставку. Но в реальной системе-то идентификаторы как-то генерятся! gen_id напрямую, или триггерами, или еще бог знает как.
Проводить тест "налысо", т.е. без минимальной привязки к практическому программированию, я не вижу смысла.

Соответственно, возникает вопрос. Либо повторить тест в том виде, в каком он был сделан, именно на 3.0.2, либо повторить тест с множеством отклонений. Понятно, что меня тоже интересует разница "вообще, при разных условиях". Но поскольку сам по себе тест займет не меньше недели (к слову, я

kdv,

экая хня. урл на ютуб в теге http движок развернул в embedded видео. тут я не виноват.

Гаджимурадов Рустам10-40 лямов записей не нужно - достаточно,
чтобы минимальная длительность превышала
30 секунд и была стабильна. Ну и 2.5 vs 3.0
как видим, тут и 1 млн записей достаточно.
Гаджимурадов РустамТак он и сейчас синтетический.
тут ты совсем неправ. Исходный тест был разработан по мотивам (и со структурой таблицы) конкретной компании. Для проверки, что там у них "распараллеливается". Выяснилось, что все это фикция.
Гаджимурадов РустамА насчет реальной системы - в реально системе это всё вряд ли будет монопольно, не говоря уже о том, что у таблицы есть зависимости.
гм, что??? в куче систем есть задача по массовой заливке данных. Понятно что в 90% этих систем может быть задача по массовому обновлению данных, но это уже несколько другая тема :-)

в частности, мы периодически выкладывали логи нашего теста oltp-emul
https://ib-aid.com/en/logs-3-0/
Это куда более "синтетично" чем просто вставка или update. Это эмуляция вполне реальной системы.

Гаджимурадов РустамОна у них без зависимостей что ли?!
каких зависимостей?
что значат "зависимости" в твоем понимании? FK? Триггеры?
Гаджимурадов РустамИ? Они заливку ночером на одной таблице запускают?
нет, постоянно заливка работает. биржевые котировки, микротранзакции.
Гаджимурадов РустамЭто разве что с репликацией какой-то сравнить, да и-то сильно вырожденный случай.
да х. с ним. Есть же у людей задачи вставки нового товара, обновления прайсов, и прочего.
чччДИнтересно бы знать цель теста. И этого и нового.
есть такая мулька - "параллельно вставлять". Этот тест показал, что эта "мулька" бессмыслена.
чччДНо какая польза разработчику от этой информации?
разработчику пользы нет, а администратору - есть. По крайней мере он может
- оценить 2.0 vs 2.1 2.5 если сидит на 2.0
- оценить restore с теми или иными опциями (-se или прочее)
чччДНаверняка, цель какая-то была. Но вот какая - непонятно.
лично у меня была цель сравнить IB и FB. Ну и остальное.
Dimitry Sibiryakovчто это замедление вставки - тоже миф и большее количество индексов увеличит распараллеливание.
ну пендец...