|
|
|
Быстрое создание записей в БД
|
|||
|---|---|---|---|
|
#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 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=36553134&tid=1552733]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
58ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
67ms |
get tp. blocked users: |
2ms |
| others: | 259ms |
| total: | 432ms |

| 0 / 0 |
