LINUX.ORG.RU

Помните тему о UUID?


0

1

Вот эту

Там зафакали идею с UUID. На работе спрашивал, тоже зафакали, мол тормозить будет. Но она красиво вписывается в мой код. Почему долго обьяснять. Вдаваться в подробности не буду, но вкратце мне это удобнее из-за генерации id сущности не в централизированном месте чтобы обеспечить уникальность.

Но что эти все разговоры стоят без прототипирования и бенчмарка?

Сделал небольшой бенч http://fileshare.in.ua/4519189

Запустил

MAVEN_OPTS="-Xbatch -Xmx800m" mvn clean package exec:java

Хотя вообщем-то память там до лампочки. Оно создает и чистит папку ./db. Вообще ничего страшного, но имею твердое правило предупреждать что моя программа что-то чистит.

Итак результат такой.

Inserts count:500000
Read count:100000
Putting 'uuid': 79.893 sec
Putting 'int': 70.266 sec
Reading 'uuid': 4.085 sec
Reading 'int': 2.734 sec
Reading 'uuid': 3.06 sec
Reading 'int': 2.687 sec
Reading 'uuid': 2.859 sec
Reading 'int': 9.188 sec
Reading 'uuid': 7.87 sec
Reading 'int': 6.901 sec
Reading 'uuid': 7.094 sec
Reading 'int': 6.844 sec

Могу это истолковать как отклонения в пределах погрешности, при достаточно высокой скорости около 30000 read/s, что в программе, которая собирается еще прочитаное отправлять по сети не будет играть роли. В программе для которой производится бенч блобы будут реально читаться и будут достаточно большими (>100 kb) чтобы их чтение занимало больше времени чем поиск

Ваши коментарии. Бенч не идеален, но думаю в определенной мере репрезентативен.

★★★★★

Reading 'uuid': 2.859 sec
Reading 'int': 9.188 sec

WAIT, OH SHI...

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

Так как в принципе выполение этого кода - малый процент от всего кода, то я имел ввиду медленнее на порядок. Если нет, то мне подходит

vertexua ★★★★★
() автор топика
Ответ на: комментарий от Divius

Это исследование специфичное для pure-java базы H2. Его нужно переделывать для Postgre. Если у тебя Linux, то тебе нужно установить Maven, распаковать архив по ссылке и выполнить ту команду которую я написал в топике. Maven остально сделает за тебя, скачает все плагины, все библиотеки, скачает СУБД, соберет программу, запустит СУБД, запустит программу, результаты будут выведены в консоль.

vertexua ★★★★★
() автор топика
Ответ на: комментарий от Divius

Ну у вас я так понимаю вообще Java не стоит. Ну пропробуйте. Интерестно посмотреть как будет на PostgreSQL. Только может лучше не надо через ORM, будет оверхед не связанный с вопросом?

vertexua ★★★★★
() автор топика
Ответ на: комментарий от vertexua

Мне интересно именно с ORM. К тому же сомневаюсь, что ORM внесёт существенную разницу.

Итак, воспроизвёл. Схема базы такая же, но добавил 3ю таблицу, где UUID хранился в VARCHAR. Используется UUID версии 1. В качестве бесполезной нагрузки в последнее поле записывался 1 кБ букв «X». Код не привожу, так как он сильно завязан на мой рабочий проект. Количество записей уменьшил.

Режим работы ORM - без autocommit. Вставка тестируется 2 раза: в первый всё добавляется одним блоком, ORM группирует вставки, в второй раз после каждой вставки делается flush.

Использовалось: PostgreSQL 8.4, Python 2.7.1, Psycopg2 2.4.1, SQLAlchemy 0.6.7.

Результаты:

$ /opt/ibd3/bin/python test.py 
Scheduling main function
Running reactor
Initializing RDBMS
Creating classes
Generating data
Inserting without flush (total count: 10000)
- INT: 4.375206 sec.
- Native UUID: 4.834080 sec.
- VARCHAR UUID: 4.819657 sec.
Inserting with flush (total count: 10000)
- INT: 90.772417 sec.
- Native UUID: 91.859727 sec.
- VARCHAR UUID: 92.680923 sec.
Reading results (total count: 10000)
- INT: 11.621372 sec.
- Native UUID: 12.285052 sec.
- Native UUID: 12.496054 sec.
Reactor stopped

Принципиальной разницы между INT и UUID, а также между «родным» UUID и просто VARCHAR я не вижу.

Divius ★★
()
Ответ на: комментарий от Divius

Можно сделать вывод что ему пофиг на тип в обеих БД, так как боттлнек не в этом. Так как естественно что 128 бит эфективнее VARCHAR. Наверное просто разница именно на этой операции несоизмерима с главной нагрузкой IO или чего-то еще. Вообще у вас как-то намного медленнее получается. У меня то embedded и H2 и так быстрее PostgreSQL если не надо сильно масштабировать, но похоже SQLAlchemy у вас дает какой-то неадекватный оверхед

У меня не было пакетного добавления. Но в моем алгоритме самой программы таки мало этого будет.

vertexua ★★★★★
() автор топика
Ответ на: комментарий от vertexua

Тут надо делать поправку на Python ещё. Ну и на прочие непредвиденные вещи. Вот, например, насчёт «128 бит эффективнее VARCHAR»: Postgres всё равно всё в строку переводит.

Так или иначе, для моих задач это подходит с избытком,

Divius ★★
()
Ответ на: комментарий от Divius

Вообще согласно бенчмаркам H2 во встроенном режиме, тоесть без оверхеда на связь быстрее в 10 раз чем PostgreSQL. Если в клиент-серверном, то меньше чем в полтора раза быстрее. Потому может быть таки боттл на связи

vertexua ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.