|
|
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Сделал простой тест Вставка в таблицу поля (a,b,c: integer) 1 000 000 записей (все СУБД внутри виртуальной машины VirtualPC) MS SQL 2005 544сек ORACLE 10 100сек CACHE 2009.1 через интерфейс Objects 70сек CACHE 2009.1 через интерфейс SQL 45сек CACHE 2009.1 через доступ к глобалям 7сек У кого есть какие комментарии? У меня вопрос - почему такое отставание MSSQL (Он при работе все время обращается к винту) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 14:14 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
авторСделал простой тест Вставка в таблицу поля (a,b,c: integer) 1 000 000 записей Записи можно вставлять по разному... Покажите, хотябы, как Вы дедали это для MS SQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 14:25 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
и снова здравствуйте, Рыцарь Печального Образа P.S. Побег за попкорном ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 14:39 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
SiemarglСделал простой тест У кого есть какие комментарии? - Штурман, приборы! - Семьдесят. - Что "семьдесят"? - А что "приборы"? Для начала нужно чётко понимать, что же, собственно, Вы хотите мерять. SiemarglУ меня вопрос - почему такое отставание MSSQL (Он при работе все время обращается к винту) ? Стеклянный шар советует проверить autocommit :) SiemarglУ кого есть какие комментарии? Да, ещё один маленький комментарий. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. Any questions? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 14:43 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
softwarerSiemarglУ меня вопрос - почему такое отставание MSSQL (Он при работе все время обращается к винту) ? Стеклянный шар советует проверить autocommit :)Тоже про это подумалось. Про постоянное обращение к диску - он родимый. Сравниваем: Код: plaintext 1. Код: plaintext Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 15:18 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Надо еще и FB испытать. А то мужики не поймут... Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 15:34 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Куда, что и кто еще вставлять будет ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 16:01 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Dmitry ArefievКуда, что и кто еще вставлять будет ?Да ты только идею подай!.. Имхо, автору достаточно наглядно показали, что сравнивать сферический insert в вакууме - дело неблагодарное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 16:05 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Senya_Linsert Да может там не insert, а alter table add column ("Вставка в таблицу поля"), а в таблице 1M записей :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 16:11 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
> Автор: Senya_L > Надо еще и FB испытать. А то мужики не поймут... Семён, а если так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 16:44 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Игорь Горбонос, ой, да вариантов можно напридумывать: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Код: plaintext 1. 2. 3. 4. тока оно зачем?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 16:48 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Да процедуру я не показал Она в приципе почти копия как у Senya_L в свертке "до кучи", только значения присваиваются через random(); BULK INSERT мне не подходят (пока) С отключением автокоммита ситуация значительно улучшилась. MS SQL 2005 25сек остальное неизменно ORACLE 10 100сек CACHE 2009.1 через интерфейс Objects 70сек CACHE 2009.1 через интерфейс SQL 45сек CACHE 2009.1 через доступ к глобалям 7сек Порядок времени исполнения почти выровнялся. Возможно можно улучшить ORACLE? Вот процедура: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 17:20 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
SiemarglВозможно можно улучшить ORACLE?Может, тоже коммитить попробовать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 17:22 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
SiemarglПорядок времени исполнения почти выровнялся. Возможно можно улучшить ORACLE? Вот процедура: Код: plaintext 1. 2. 3. чо за фигня? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 17:24 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Siemargl Порядок времени исполнения почти выровнялся. Возможно можно улучшить ORACLE? вот так нуна: Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 18:23 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Yo.!, это трик, не совсем честный по логике. Кроме того, рекурсия - дорогое удовольствие и у меня, например, по памяти не проходит. ORA-04031: unable to allocate 44 bytes of shared memory ("large pool","unknown object","kxs-heap-w","cursor work heap") ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 19:21 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Siemargl wrote: > У кого есть какие комментарии? Я думаю, тут дело в неверных замерах. А в случае кэша -- возможно и непонимание того, что он делает, и эквивалентность этого тому, что делают другие СУБД (я например не понимаю этого. Ты понимаешь ?) Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 19:35 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Siemargl wrote: > С отключением автокоммита ситуация значительно улучшилась. > MS SQL 2005 25сек Дело не в автокоммите, а в размере транзакции. Если 1 миллион транзакций по одной записи -- будет медленно. Если 10 тыщ транзакций по 100 записей -- будет быстрее. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 19:38 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
SiemarglYo.!, это трик, не совсем честный по логике. это не трюк, а так люди работают с rdbms. ваш вариант - пример абсолютной безграмотности и некомпетентности. обычно манией все решать неестественными реляционым бд циклами пресущи фокспро-гайз и пораженных кашей. Siemargl Кроме того, рекурсия - дорогое удовольствие и у меня, например, по памяти не проходит. дефолтной инсталяции oracle xe памяти хватает, нефиг лезть в настройки не обладая хотя бы минимальной квалификацией ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 19:51 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Yo.!, Инсталляция почти дефолтная, крутить ничего не надо было для тест-системы. Изменена только ALTER SYSTEM SET SHARED_POOL_SIZE='100M' SCOPE=spfile; по инструкции к apex v3 И не надо страдать манием величия (запроса) - единственным запросом выгребая тучу памяти. А остальным что? Админ БД побьет, если поймает. В реальности задача конечно не крутит циклы в PL/SQL, а внешней программой пишет по одной записи. У нее свои циклы (по приходу данных) и таких табличек - скажем, типично тысяча. А это-искусственная ее имитация. MasterZiv Не понимаю. Самая прозрачная структура хранения кстати, у Кэша, который я впервые вижу, а вот остальные на что тратят время в тривиальном случае - мне непонятно. Это как NTFS - (и структура хранения кстати, в СУБД похожа) - и надежная и иногда очень быстрая, но периодически тратит на свои внутренние дела ХЗ сколько времени. А кэш в этой аналогии как FAT. А замеры то верные - в одной виртуалке, с дефолтными настройками. С индексами структура еще усложнится, и не нужны они (пока и так не совем понятно что происходит). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 20:18 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
MasterZiv Siemargl wrote: > С отключением автокоммита ситуация значительно улучшилась. > MS SQL 2005 25сек Дело не в автокоммите, а в размере транзакции. Если 1 миллион транзакций по одной записи -- будет медленно. Если 10 тыщ транзакций по 100 записей -- будет быстрее. +1 XML'ем можно "лить" данные, уж на то пошло. И что за мания сравнивать скорость вставки тупо создав программный цикл на сервере? Задача сервера БД - обслуживать клиентские запросы (простите уж за банальности, они для автора :)), а оценивать скорость вставки по запросам, как все мои выше указанные - это полная фигня. Я-то хоть проикалывался ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 20:23 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Visual Foxpro 9 Код: plaintext 1. 2. 3. 4. 5. 6. 2.703 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 20:30 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
SiemarglYo.!, Инсталляция почти дефолтная, крутить ничего не надо было для тест-системы. Изменена только ALTER SYSTEM SET SHARED_POOL_SIZE='100M' SCOPE=spfile; по инструкции к apex v3 брехня. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. SiemarglИ не надо страдать манием величия (запроса) - единственным запросом выгребая тучу памяти. память - она резиновая и дешевле картошки, а вот и/о - дорого, вот его беречь нуна. SiemarglА остальным что? Админ БД побьет, если поймает. гнать таких админов на пенсию, в крайнем случае, если где-то сохранилось, в зад на кашу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 20:33 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
авторС индексами структура еще усложнится, и не нужны они Можно я буду Вас цитировать??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 20:46 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Yo.!SiemarglИ не надо страдать манием величия (запроса) - единственным запросом выгребая тучу памяти. память - она резиновая и дешевле картошки, а вот и/о - дорого, вот его беречь нуна. В районе 5т-10т записей на батч (зависит от <длинный список 1>) перестает существенно расти производительность. Заключать всю "нарезку" или только один батч в транзакцию зависит больше <длинный список 2>. Первый и второй списки слабо пересекаются ... Так что - кто как порежет. А кто и одной кучей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 21:16 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Yo.!, Поправьте меня, но ваша команда set sga sga_target без SCOPE действует только до перезапуска БД. Что и видно при старте, что ее 128М =) Ну и память в Ора SGA, которая используется для рекурсии, совсем не резиновая в мультиюзер. Нечего демагогию разводить. > pkarklin Цитировать можно, но полностью и без отрыва от контекста, который есть "в данном случае" А результаты такие -в простую базу и писать легче. См.FoxPro и Cache.Direct -при нормальном доступе (SQL) скорость такой операции сравнима у разных БД. Только у каждой свои приколы/мульки -использовать надо инструмент, подходящий под задачу А вообще, сравнение родилось случайно, т.к. мне нужен был нормальный ОБЪЕКТНЫЙ доступ, с которым я наткнулся на Кэше, а проверка скорости началась из вопроса "а не сильно ли медленно оно работает (и как)?". Ну и задача была под руками. Побочный вывод - рекламе верить нельзя вообще, а Кэшу в частности (про скорость). Так что для меня тема закрыта. Всем сочувствовавшим спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 22:06 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Fox5631 Респект и уважение! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2009, 23:30 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
SiemarglYo.!, Поправьте меня, но ваша команда set sga sga_target без SCOPE действует только до перезапуска БД. Что и видно при старте, что ее 128М =) в данном случае не важно, 28 мб никакой роли не играют: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. SiemarglНу и память в Ора SGA, которая используется для рекурсии, совсем не резиновая в мультиюзер. Нечего демагогию разводить. с чего ты решил, что этот запрос съест сколько нибудь заметное кол-во памяти ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2009, 01:19 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
SiemarglЦитировать можно, но полностью и без отрыва от контекста, который есть "в данном случае" Обязательно! С линком на первый пост в этом топике. SiemarglА результаты такие -в простую базу и писать легче. См.FoxPro и Cache.Direct Еще легче просто в файл. И что?! Siemarglпри нормальном доступе (SQL) скорость такой операции сравнима у разных БД. Только у каждой свои приколы/мульки Что есть "нормальный доступ"?! И что Вы относите к приколам\мулькам в каждой из "протестированных Вами СУБД"? Siemarglиспользовать надо инструмент, подходящий под задачу Упс... А где, собственно то задача??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2009, 08:57 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Siemargl -использовать надо инструмент, подходящий под задачу Как представляется по предшествующим постам, существуют риски определение "подходимости" инструмента "под задачу" может оказаться более сложной задачей, чем исходная типа задача. По крайней мере, для некоторых задачерешателей. Потому все еще стоит рассмотреть более принятый подход: выбрать инструмент "под как моно больше задач" раз и на долго. По крайней мере, если идет речь о "задачах", "над" которыми ожидается инструмент типа СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2009, 01:16 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
vadiminfoПотому все еще стоит рассмотреть более принятый подход: выбрать инструмент "под как моно больше задач" раз и на долго. Fox имеешь в виду ? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2009, 07:41 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
А вот еще результат к размышлению. Берем NHibernate 2.1, тот же SQL2005 express и миллион объектов. Время: Time to insert: 00:06:02.7215680 Напомню, что в SQL-процедуре создание заняло 26сек. Продолжим комментарии? Для всякий случай - основной код ниже. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2009, 01:19 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
SiemarglСделал простой тест Вставка в таблицу поля (a,b,c: integer) 1 000 000 записей (все СУБД внутри виртуальной машины VirtualPC) MS SQL 2005 544сек ORACLE 10 100сек CACHE 2009.1 через интерфейс Objects 70сек CACHE 2009.1 через интерфейс SQL 45сек CACHE 2009.1 через доступ к глобалям 7сек У кого есть какие комментарии? У меня вопрос - почему такое отставание MSSQL (Он при работе все время обращается к винту) ? Неплохо. У меня Sqlite через sql сумел то же самое сделать за 61 сек. 7 сек скорее всего из-за того что не парсится SQL http://webfile.ru/4377782 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2010, 14:27 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Толстый_Троль Неплохо. У меня Sqlite через sql сумел то же самое сделать за 61 сек. 7 сек скорее всего из-за того что не парсится SQL http://webfile.ru/4377782 Все измерения я проводил в виртуалке. Скорость в ней падает вдвое (минимум). Текущая таблица выглядит так: MS SQL 2005 25сек ORACLE 10 100сек CACHE 2009.1 через интерфейс Objects 70сек CACHE 2009.1 через интерфейс SQL 45сек CACHE 2009.1 через доступ к глобалям 7сек ORM NHibernate 2.1 + SQL2005 6 минут 2 сек Firebird 2.5 7.4сек ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2010, 14:54 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
А теперь тесты Кэтрин В транзакционном режиме TxF 51.8 cек В нетранзакционном режиме 16.9 сек Это существенно быстрее NHibernate Код Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2010, 15:07 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Hello, SergSuper! You wrote on Tue, 23 Mar 10 13:07:58 GMT: SergSuper S> это что? новый TJ7 ?достойный конкрент! -- With best regards, Мимопроходящий. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2010, 16:21 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Siemargl, Код Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. Результаты для Caché 2010.2.FT1: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Но Вы можете комбинировать подходы: где важна скорость - используйте SQL (или глобалы), где важно удобство работы или есть сложная обработка - объекты. В Hibernate есть поддержка диалекта Caché. PS: если Вы делали тест на однопользовательской версии, то в ней ограничен кэш базы данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2010, 14:49 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Дополнение SQLite 3.6.23 4,095 сек Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2010, 10:16 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
SiemarglYo.!, Поправьте меня, но ваша команда set sga sga_target без SCOPE действует только до перезапуска БД. Что и видно при старте, что ее 128М =) Ну и память в Ора SGA, которая используется для рекурсии, совсем не резиновая в мультиюзер. Нечего демагогию разводить. > pkarklin Цитировать можно, но полностью и без отрыва от контекста, который есть "в данном случае" А результаты такие -в простую базу и писать легче. См.FoxPro и Cache.Direct -при нормальном доступе (SQL) скорость такой операции сравнима у разных БД. Только у каждой свои приколы/мульки -использовать надо инструмент, подходящий под задачу А вообще, сравнение родилось случайно, т.к. мне нужен был нормальный ОБЪЕКТНЫЙ доступ, с которым я наткнулся на Кэше, а проверка скорости началась из вопроса "а не сильно ли медленно оно работает (и как)?". Ну и задача была под руками. Побочный вывод - рекламе верить нельзя вообще, а Кэшу в частности (про скорость). Так что для меня тема закрыта. Всем сочувствовавшим спасибо. Да писать - то ерунда. А почему бы Вам не попробовать более реальную задачу. 1. Требуется создать 1 000 000 записей. 2. Каждая запись имеет уникальный индекс целого типа. 3. Содержание записи является суммой трех слагаемых. 4. Каждое слагаемое есть результат вычитки из уже созданных записей по индексу,находящемуся в диапазоне от 1 до до индекса последней записи, взятого случайным образом. 5. Самая первая запись может иметь значение равное единице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2010, 19:48 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Что-то "тестеры-теоретики" притихли, или страшно даже затевать подобный эксперимент. Я вот попробовал на бытовой "железяке", купленной пять лет назад, и получил примерно 24 секунды. Cache 2009.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 15:24 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
п.4 не поясните? что такое "вычитка"? и как понять "до индекса последней записи, взятого случайным образом"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 16:14 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
SergSuper, Каждое слагаемое суммы, есть уже записанное значение в БД (его необходимо прочитать). Место хранения такого слагаемого определяется индексом записи. Если уже было произведено 100 000 записей, то слагаемое может находиться в любой из этих записей от 1 до 100 000. Конкретное значение индекса для каждого слагаемого определяется случайным образом в этом диапазоне. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 16:53 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
SergSuper, Кстати, вот тестовый код. Функция старт на входе получает 1000 000 количество вставляемых записей (по умолчанию - 100). Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 17:53 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
плохо MS SQL со случайными числами работает, выглядит некрасиво Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 1:08 двухядерный офисный нотебук ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 18:39 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
SergSuper, А теперь не удаляя существующие данные выполняем 1 000 000 апдейтов по тем же правилам. Причем обновляем случайные записи на множестве от1 до 1 000 000. у меня 29 сек. Вот код. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 19:40 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
1:20 давайте чего-нибудь без случайных чисел :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 20:02 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
например запись содержит три ссылки на записи с суммой надо подсчитать общую сумму всех сумм из трёх полей Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 20:10 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
SergSuper, Согласен, ряд моментов вносит деструктив в чистоту собственно эксперимента. Эти моменты, считаю не столь значимые, чтобы на них зацикливаться. Экспериментом является скорость работы движка СУБД по записи и чтению регулярного потока данных. А способы реализации отдельных функций в различных системах могут вносить большую погрешность в само измерение, поскольку разработчики не должны удовлетворять наши с Вами прихоти - у них другие цели. Вот если бы заталкивать случайный поток данных из внешнего окружения, одинаковый к Вам и ко мне, тогда можно было бы и сравнивать. Теперь по поводу Вашего предложения. Я не силен в реляционной теории, использую реляционную модель данных в ограниченном режиме, только для совместимости с внешними системами, отчетными системами и еще по ряду причин. При этом в реляционные хранилища стараюсь вносить данные уже предварительно обработанные, насколько это можно, и оптимизированные на вычитку. Насколько я понял необходимо подсчитать сумму из трех слагаемых на всем множестве данных, где каждая запись хранит кроме собственно данных еще и три индекса по которым нужно читать сами данные. Индексы случайным образом распределены в диапазоне от 1 до 1 000 000 Количество записей тоже 1 000 000. Вы за 5 сек выполнили весь подсчет. Если я неправильно понял задачу, то поправьте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2010, 23:57 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
да, так у Вас должно получится быстрее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2010, 11:02 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Вставка с учётом ранее введённых данных Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. Код: plaintext 1. 2. Подсчёт общей суммы Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2010, 13:41 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Немного удалось улучшить результат, распараллелив запрос в несколько потоков, вернее процессов: Распараллеленный запрос Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2010, 18:00 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Oracle 11R2: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. PL/SQL procedure successfully completed. Elapsed: 00:00:00.34 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.12.2010, 18:03 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
Alexander Ryndin, Там была опечаточка к коде: numrec number :=100000 1000000; И Все измерения я проводил в виртуалке. Скорость в ней падает вдвое (минимум). Причем на обычном ноуте среднего класса, а не продакшн сервере ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2011, 11:37 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
SiemarglAlexander Ryndin, Там была опечаточка к коде: numrec number :=100000 1000000; И Все измерения я проводил в виртуалке. Скорость в ней падает вдвое (минимум). Причем на обычном ноуте среднего класса, а не продакшн сервере )У меня обычный офисный ноут. Настройки Oracle по default - наверняка еще что-то можно подтюнить. С исправленным результатом: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Elapsed: 00:00:03.15 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2011, 18:03 |
|
||
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#18+
SiemarglAlexander Ryndin, Там была опечаточка к коде: numrec number :=100000 1000000; И Все измерения я проводил в виртуалке. Скорость в ней падает вдвое (минимум). Причем на обычном ноуте среднего класса, а не продакшн сервере ) Ты прикалываешься? Результаты продакшн-серверов здесь . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2011, 15:08 |
|
||
|
|

start [/forum/topic.php?all=1&fid=35&tid=1552733]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
33ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
81ms |
get tp. blocked users: |
1ms |
| others: | 234ms |
| total: | 390ms |

| 0 / 0 |
