|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
MBGSiemarglMBG, Давайте постановку задачи (с достаточным упрощением) и проверим порядок. Блокироваться в памяти быстрее, чем блокироваться в кэше БД и в блоках на диске. Только реализации задачи на SQL с Вас. Например, вот такой тест: Тестирование SQLite 3.6.17-mobigroup.2 на больших таблицах У вас - с многопоточной модификацией in-memory структуры при добавлении по одной записи, с частотой 1000 записей в секунду, с поддержкой индексов по полям и композитного (как описано в статье). У меня - добавление записей пакетное ежесекундно, число записей в "пакете" - 1000. Для измерения скорости запросов скриптик напишу и статью дополню. Измеряем: 1. Коэффициент доступности в процентах. Например, 80% означает, что 80% времени данные доступны для выборки или что данные блокируются на 0,2 секунды ежесекундно. 2. Скорость выборки набора записей, удовлетворяющих условию (запрос по одному индексу и по композитному, как в статье). В SQL делаю count(*), чтобы избежать затрат времени на передачу извлеченных данных - т.е. измеряется только время непосредственно выборки. Предлагаю таки закончить по данному заданию. С небольшими уточнениями -тестируем на готовой базе 10М -добавление записей происходит 100 потоками по 1000 записей в сек -1 поток читающий - select sum(a1+a2+a3+a4) from facts where a1=2 -ну и конечно ai - 64бит ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 13:15 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
pavlikkkMBG, протестил я токиокабинет. думал, вот оно, то что мне надо, когда встретил их "рекламу":) В результате, эта хрень вообще не может работать с большим объемом данных. Если ничего не тюнить, то начинает тормозить уже на 100000 записей, причем время вставки растет явно быстрее чем линейно, скорее экспоненциально. Потрахавшись с настройками, выделив здоровый кеш и размер bucket'a в b-дереве, удалось затолкать туда 23 миллиона записей, дальше не реально. Короче, работает она только до тех пор, пока структуры данных в память помещаются. ... Вот еще ссылка на тесты "мега-крутой" токиокабинет: http://www.dmo.ca/blog/benchmarking-hash-databases-on-large-data/ Точно такая же проблема. В общем, никому не рекомендую. Так, сначала про эскулайт были желающие на два порядка лучше решение сделать, теперь то же самое с токиокабинет? Сейчас посмотрим... Запускаю тесты, база токиокабинет типа хэш на 10М записей размером 690M создается за 134 секунды, на 20М записей размером 996M - за 280 секунд. Это на ноуте с так себе винтом и процессором. Вполне себе достойная скорость, никакого падения производительности в помине нет. Может, не надо с настройками трахаться, а лучше маны почитать? P.S. Одна верная мысль вами названа, но вы сами не поняли ее глубины. А именно "пока структуры данных в память помещаются". Только вот здесь "структуры данных" - не то, что вы думаете. В эскулайте, кстати, аналогично. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 13:27 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
Siemargl Предлагаю таки закончить по данному заданию. С небольшими уточнениями -тестируем на готовой базе 10М -добавление записей происходит 100 потоками по 1000 записей в сек -1 поток читающий - select sum(a1+a2+a3+a4) from facts where a1=2 -ну и конечно ai - 64бит Это вы в памяти добавляете в 100 потоков, а у нас в базу пишется пакетно из одного потока - жесткий диск он не резиновый. А вот ридеров - много, скажем, 1000 потоков. Смотреть для одного читающего потока смысла нет, посколько в вебе на каждую операцию записи приходится, как минимум, десяток операций чтения. Выборку делать по композитному индексу, т.к. выбирать порядка миллиона результатов "where a1=2" на практике смысла не имеет, эдак мы скорость ввода-вывода тестировать будем (для вас этот тест вообще оптимально кодируется полным перебором). ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 13:38 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
MBG, Смысл не столько в абсолютной скорости, а задержках при работе с кэшем и системными вызовами sqlite - пусть кэш будет любого размера. Может быть трафик на запись можно взять поменьше, чтобы до диска почти не доставало. Но ограничиваться читателями нельзя - чтение то неблокируемое, а померять хотим блокировку. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 14:52 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
MGB, хорошо, может я не прав. Дайте мне исходники тестов, я попробую прогнать у себя. Загоните в него 100М записей, по 10М за раз. Между ними закрывая базу. MGBТак, сначала про эскулайт были желающие на два порядка лучше решение сделать, теперь то же самое с токиокабинет? Нет у меня желания что-то свое делать. Есть желание готовым воспользоваться. Не правильно вы меня понимаете. Код: 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.
Прогоните мой тест, не получив падения производительности. И приведите исходники своего теста. Умные все такие.. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 15:22 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
SiemarglMBG, Смысл не столько в абсолютной скорости, а задержках при работе с кэшем и системными вызовами sqlite - пусть кэш будет любого размера. Может быть трафик на запись можно взять поменьше, чтобы до диска почти не доставало. Но ограничиваться читателями нельзя - чтение то неблокируемое, а померять хотим блокировку. По дефолту эскулайт делает полный сброс данных на диск, с получением подтверждения от ОС. Это очень затратная операция, хоть 1 байт записывается, хоть мегабайт. Потому необходимо данные записывать пакетно. Если же fsync отключить, то при сбое ОС или приложения есть вероятность повреждения БД. Это ограничение действует для всех приложений. К примеру, у постгреса это параметр fsync в конфиге. Проверить блокировки можно, отключив гарантированную синхронизацию записи, но для продакшена это не интересно. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 15:23 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
MGB P.S. Одна верная мысль вами названа, но вы сами не поняли ее глубины. А именно "пока структуры данных в память помещаются". Только вот здесь "структуры данных" - не то, что вы думаете. В эскулайте, кстати, аналогично. Один вы, о гуру, понимаете всю глубину. Прозрев взглядом, что именно я думаю, говоря "структуры данных":) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 15:29 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
pavlikkk, В комплекте с токиокабинет предлагается набор тестовых программ. В том числе tchtest. Покажите ваши результаты tchtest для 20М базы. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 15:30 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
MBG Проверить блокировки можно, отключив гарантированную синхронизацию записи, но для продакшена это не интересно. Это можно воспринимать, как добровольную сдачу (resign) для задачи ТС (и своей) ? =) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 15:37 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
MBG, не могу показать результаты для 20M базы. Вот на этом месте подвисло и висит уже минут 10. C каждым миллионом работает ощутимо медленнее. /usr/ports/databases/tokyocabinet/work/tokyocabinet-1.4.41/tchtest write tt.tbd 10000000 <Writing Test> seed=2592105062 path=tt.tbd rnum=10000000 bnum=-1 apow=-1 fpow=-1 mt=0 opts=0 rcnum=0 xmsiz=-1 dfunit=0 omode=0 as=0 rnd=0 ......................... (01000000) ......................... (02000000) ......................... (03000000) ......................... (04000000) ......................... (05000000) ......................... (06000000) ......................... (07000000) .............. FreeBSD 7.2-STABLE FreeBSD 7.2-STABLE #1: Mon Oct 5 10:33:30 UTC 2009 amd64 ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 15:50 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
MGB, объясните мне убогому, как же это оно у вас так быстро и хорошо работает? Мож нам на продакшен ваш ноут поставить? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 15:52 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
SiemarglMBG Проверить блокировки можно, отключив гарантированную синхронизацию записи, но для продакшена это не интересно. Это можно воспринимать, как добровольную сдачу (resign) для задачи ТС (и своей) ? =) Что-то вы путаете - топикстартеру я в самом начале описал реализацию на основе пакетной записи на диск. И если поискать у меня в деб-репозитории, то можно найти реализацию на тикле коллектора лога с множества АТС с in-memory БД, синхронизируемой с дисковой. Вполне себе продакшен-решение, давно и успешно работает. Заметьте - конкурентный доступ _работает_, но для многих миллионов записей в сутки _эффективнее_ делать пакетные модификации. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 16:04 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
pavlikkk, Память свободная есть? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 16:05 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
Siemargl, 2 Гб свободной памяти. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 16:08 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
pavlikkkMGB, объясните мне убогому, как же это оно у вас так быстро и хорошо работает? Мож нам на продакшен ваш ноут поставить? Ну, ноут-то ладно, главное меня не трогать :-) Все просто - я начал с пятиминутного чтения мана: "Tokyo Cabinet: a modern implementation of DBM"Effective Implementation of Hash Database Tokyo Cabinet uses hash algorithm to retrieve records. If a bucket array has sufficient number of elements, the time complexity of retrieval is "O(1)". That is, time required for retrieving a record is constant, regardless of the scale of a database. It is also the same about storing and deleting. Collision of hash values is managed by separate chaining. Data structure of the chains is binary search tree. Even if a bucket array has unusually scarce elements, the time complexity of retrieval is "O(log n)". Как видите, я взял такие параметры, чтобы попасть в O(1). А у вас скорость определяется O(log n) при большом n. Код: 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.
Если взять вдвое меньше ячеек, время окажется равным 537 секунд. И так далее. Подсчет вероятности коллизии и, соответственно, времени на вставку в зависимости от числа ячеек приведен в упомянутом выше руководстве, равно как и рекомендация взять число ячеек равным половине от кол-ва записей в базе. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 16:23 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
pavlikkkMGB P.S. Одна верная мысль вами названа, но вы сами не поняли ее глубины. А именно "пока структуры данных в память помещаются". Только вот здесь "структуры данных" - не то, что вы думаете. В эскулайте, кстати, аналогично. Один вы, о гуру, понимаете всю глубину. Прозрев взглядом, что именно я думаю, говоря "структуры данных":) Пойдем простым логическим путем: думаете вы не то, что написано в мане, иначе результаты не были бы столь плачевны :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 16:26 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
MBG, попробуйте лучше вот это и расскажите про результаты. оно больше соответствует моим тестам. /usr/ports/databases/tokyocabinet/work/tokyocabinet-1.4.41/tchtest rcat tt.tbd 10000000 20000000 Тоже o(1) ? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 17:18 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
pavlikkkMBG, попробуйте лучше вот это и расскажите про результаты. оно больше соответствует моим тестам. /usr/ports/databases/tokyocabinet/work/tokyocabinet-1.4.41/tchtest rcat tt.tbd 10000000 20000000 Тоже o(1) ? А тут вы врубили алгоритм слияния при конфликтах - в итоге словили кучу операций перезаписи и перемещения - выполняется обновление на месте с перемещением кучи блоков, чтобы освободить место. Имхо практически это можно применить разве что в синтетических тестах SSD vs. HDD. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 17:37 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
Мда, с высоты моих 22 лет эти слова не понять. В общем, не рабочая это хрень. По всем моим теста, а не тем, которые они приводят у себя в пакете. Причем, это не только мое мнение, а всех, кто пытался использовать на продашене. Ссылки давать не буду, кому надо сами посмотрят. Тем не менее, cпасибо за дельные советы по sqlite!:) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 18:21 |
|
|
start [/forum/topic.php?fid=54&msg=36544554&tid=2009361]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
99ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 221ms |
0 / 0 |