|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
SiemarglMBG, Лимит чего? Вставили запись, удалили, снова вставили - 32 бит идентификаторы со временем закончатся. Даже если старые данные на диск сбрасывать, идентификаторы-то должны быть уникальными. При интенсивности вставки 1000 записей в секунду (не вы ли говорили, что это мало?) 32 бит идентификаторов хватит на месяц примерно. Siemargl 100М записей в память не поместится. Расход 100Мбайт на 1М записей. Итого для 32 бит без извращений меньше 20М. Ну вот вы и встали на первые грабли - у топикстартера гигабайты данных в сутки, а у вас в винде 2 Гб на процесс лимит. То есть ваше решение - немасштабируемое, очевидно. Если вы посмотрите на мои тесты, то в эскулайт на 1М записей плюс 4 индекса по столбцам плюс праймари кей плюс композитный индекс по всем столбцам требуется 73M, притом, что используются 64-бит integer. А у вас 100М на 32-бит integer - разбазариваете вы память, не так ли? Полагаю, с этим все понятно - эскулайт примерно вдвое экономичнее расходует память. Это ваши вторые грабли. Делайте 64-бит integer и впихивайте сколько влезет записей в память, измеряйте скорость двух вышеназванных селектов, усредняя, скажем, по 1000 итераций. И скорость вставки измеряйте на этой же базе - при 1М записей может работать быстро, а при увеличении количества данных может и начать еще как "тормозить". ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 00:19 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7.
А это отнюдь не вставка по одной записи, а пакетная операция. Блокируйте на каждую запись и смотрите скорость вставки 1000 записей на заполненной базе. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 00:26 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
Покажете свои цифры, тогда будет видно. Пока что я утверждал только лишь, что в памяти будет на 2 порядка быстрее, чем в базе, а те то, что всю базу надо в ней хранить ))) Это же только кэш - и не более того. Конечно, в памяти отмасштабируется, сколько есть в системе ОЗУ и не больше. 64Бит ОС и компилятор поможет. Это серверное решение, а сию секунду я на нетбуке с 512М сижу ) Пока в своп не уходит на 4м мильене - не тормозит. Завтра днем на рабочем буке погоняю до 10М. А пока, в общем, Ваш ход. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 00:34 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
SiemarglПокажете свои цифры, тогда будет видно. Пока что я утверждал только лишь, что в памяти будет на 2 порядка быстрее, чем в базе, а те то, что всю базу надо в ней хранить ))) Это же только кэш - и не более того. Конечно, в памяти отмасштабируется, сколько есть в системе ОЗУ и не больше. 64Бит ОС и компилятор поможет. Это серверное решение, а сию секунду я на нетбуке с 512М сижу ) Пока в своп не уходит на 4м мильене - не тормозит. Завтра днем на рабочем буке погоняю до 10М. А пока, в общем, Ваш ход. Совершенно некорректно сравнивать, так как я на 100М базе тестирую, а вы на 1М, даже глубина b-tree индексного дерева разная. Но все же: Код: plaintext 1. 2. 3. 4.
Код: plaintext 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 00:43 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
Все же приведу и такой результат: Код: plaintext 1. 2.
Здесь итоговая выборка содержит 3М записей. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 00:49 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
Даже на нетбуке (ПентиумМ 1.7/ 512М) 2:Inserted: 3000000 1:Simple index count (a1 = 2) = 166402 0:Simpletest a1 = takes 0.031 seconds. 1:Component index count {2,2,2,2} = 33 0:Simpletest a1 = takes 0.000 seconds. Надо понимать, ваше 0.516 - это полсекунды? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 02:25 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
SiemarglДаже на нетбуке (ПентиумМ 1.7/ 512М) Это не "даже", а очень плохие результаты. См. ниже. Siemargl 2:Inserted: 3000000 1:Simple index count (a1 = 2) = 166402 0:Simpletest a1 = takes 0.031 seconds. 1:Component index count {2,2,2,2} = 33 0:Simpletest a1 = takes 0.000 seconds. Полный бред: "0.000 seconds". Кому нужны такие "измерения"? SiemarglНадо понимать, ваше 0.516 - это полсекунды? Да. У вас 0.031 секунды на 166402 записей в RAM, это будет 0.565 секунды на 3М записей - больше, чем эскулайт тратит на обработку данных в 30-ти кратно большей по размерам дисковой БД! ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 12:43 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
MBG, Вы невнимательны. 0.031с - это время поиска в 3М записей. Выборка же с а1=2 составляет 166402 записи из 3М. Кстати это неточный результат - скорее даже худший - надо было 10 раз прогнать. 0.000с - всего лишь означает, что поиск меньше 1мс Сейчас прогоню на нормальном железе. Кроме того, параллельную работу из разных потоков я от Вас не вижу. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 12:57 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
MBGУ вас 0.031 секунды на 166402 записей в RAM, это будет 0.565 секунды на 3М записей - больше, чем эскулайт тратит на обработку данных в 30-ти кратно большей по размерам дисковой БД! Железо у вас все-таки разное. Но в то, что бустовые контейнеры могут тормозить на больших объемах данных, охотно верю. Скорее всего, не для того он сделан. А вообще, очень интересная у вас дискуссия. MBG, я уже говорил, что не имею опыта работы с sqlite. Подскажите, пожалуйста, как грамотно настроить его под такую задачу. Я так понимаю, надо отключить транзакции, поменять размер страницы чтоб соответствовао ОС, еще что-то сделать? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 13:04 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
SiemarglMBG, Вы невнимательны. 0.031с - это время поиска в 3М записей. Выборка же с а1=2 составляет 166402 записи из 3М. Кстати это неточный результат - скорее даже худший - надо было 10 раз прогнать. Внимателен. Для сравнимости результатов на вашей мелкой базе делаем простейшую пропорцию: 3033113 записей вернул эскулайт в моем тесте, у вас 166402 записей, значит, ваше время поиска 0.031с нужно увеличить в (3033113/166402) раз, что дает 0.565 секунды. То есть, даже если на больших базах у вас нет регрессии, все равно тормозит. Siemargl 0.000с - всего лишь означает, что поиск меньше 1мс В эскулайте поиск на 100М записей выполняется за 36 микросекунд. Какой смысл в таких данных? Ровно так же можно сказать, что у вас поиск занял меньше 1 дня или года, информации - ноль. SiemarglКроме того, параллельную работу из разных потоков я от Вас не вижу. Умножайте скорость выборки на число ядер, т.е. на моем железе - на 4. Именно это получаем, когда запускаем 4 экземпляра тестового скрипта - каждый из них выполняется все с той же скоростью, т.к. они никак не взаимодействуют. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 13:06 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
pavlikkkMBGУ вас 0.031 секунды на 166402 записей в RAM, это будет 0.565 секунды на 3М записей - больше, чем эскулайт тратит на обработку данных в 30-ти кратно большей по размерам дисковой БД! Железо у вас все-таки разное. Но в то, что бустовые контейнеры могут тормозить на больших объемах данных, охотно верю. Скорее всего, не для того он сделан. А вообще, очень интересная у вас дискуссия. Признаться, я надеялся, что оппонент на С напишет b-tree :-) В этом случае можно получить очень интересные результаты, я когда-то пробовал. Но организация многопоточной работы, поддержка дисковых и in-memory данных, транзакции - слишком много всего нужно для "средней" системы, и в результате эскулайт оказывается и быстрее и намного надежнее. pavlikkkMBG, я уже говорил, что не имею опыта работы с sqlite. Подскажите, пожалуйста, как грамотно настроить его под такую задачу. Я так понимаю, надо отключить транзакции, поменять размер страницы чтоб соответствовао ОС, еще что-то сделать? Транзакции в нормальных СУБД не отключаются, это не мускуль :-) Размер страницы ставьте 8к, размер кэша 1 или 2 гига - задается в страницах, пересчитайте. Кэш критичен для вставки - для модификации индексов. Индекс у вас, как я себе представляю, нужен один композитный по полям user_id,save_date. Продумайте разделение данных по базам - например, по неделям или по месяцам, чтобы в одной базе не хранилось слишком много записей. В данном случае - лучше бы в базе держать не более 20 - 50 миллионов записей. Иначе представьте, что однажды нагрузка подскочит втрое, а у вас и так сотни миллионов записей в одной базе - рискуете огрести самые неприятные проблемы, поскольку на таких масштабах систему не тестировали. В общем, должен быть запас - тестируете на 100М записей - используете 20М, тестируете на 250М - используете 50М. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 13:35 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
MBG, Я собственно тоже пробавал написать b-tree, и даже написал. Но как представишь, сколько еще нужно сделать...:) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 13:45 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
MBGSiemarglMBG, Вы невнимательны. 0.031с - это время поиска в 3М записей. Выборка же с а1=2 составляет 166402 записи из 3М. Кстати это неточный результат - скорее даже худший - надо было 10 раз прогнать. Внимателен. Для сравнимости результатов на вашей мелкой базе делаем простейшую пропорцию: 3033113 записей вернул эскулайт в моем тесте, у вас 166402 записей, значит, ваше время поиска 0.031с нужно увеличить в (3033113/166402) раз, что дает 0.565 секунды. То есть, даже если на больших базах у вас нет регрессии, все равно тормозит. Это теория. Count(*) необязательно работает с линейной зависимостью. MBG SiemarglКроме того, параллельную работу из разных потоков я от Вас не вижу. Умножайте скорость выборки на число ядер, т.е. на моем железе - на 4. Именно это получаем, когда запускаем 4 экземпляра тестового скрипта - каждый из них выполняется все с той же скоростью, т.к. они никак не взаимодействуют. Вот тут код в студию, ибо непонятно как за 100мс запущено несколько потоков. Реализуем задачу по Вашему же ТЗ. Вот на рабочем буке для 10М. >Inserted: 10000000 0:Insert 10M takes 64.900 seconds. ---прошла вставка в память 10М записей 0:Simple index count (a1 = 2) = 1111127 0:Simpletest a1 = takes 122 ms. ---10 раз прогнали поиск по условию a1=2 и получили count(*). время на 1 поиск усредненное. 0:Simple index count (a1 = 2) = 1576 0:Simpletest a = {2,2,2,2} takes 4 ms for 100 execs. ---10000 раз прогнали поиск по комплексному ключу и получили count(*). время на 100 поисков усредненное. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 13:45 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
Сделал базу 10М записей согласно тому распределению, что предложено в моем блоге для 10М базы. Результаты: Код: plaintext 1. 2. 3. 4. 5. 6. 7.
P.S. Если кучу ваших цифр я правильно понимаю, то вы взяли распределение для 1М базы, а не для 10М. В статье отнюдь не случайно выбраны именно такие распределения. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 14:57 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
Да у меня было от 1 до 9 (я менял, а то не сходилось с вашими кол-вами). Но мне же хуже. Надо понимать, у Вас milliseconds =) Итого получаем: Комплексный ключ 41.87ms vs 0.04ms Простой индекс 93839ms vs 122ms ???? Опять же, приложил exe, может найдете где запустить. 10М записей, распределение поменял на 1..18 Для запуска нужны msvcp90.dll, msvcr90.dll ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 15:29 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
SiemarglДа у меня было от 1 до 9 (я менял, а то не сходилось с вашими кол-вами). Но мне же хуже. Надо понимать, у Вас milliseconds =) microseconds - это микросекунды. Итого: комплексный ключ - одинаково, простой индекс в эскулайте быстрее. И это работа с дисковой БД, да и тесты у меня написаны на тикле У вас же структуры в памяти и написано на С++. Так где ваши искомые 2 порядка разницы в быстродействии? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 15:58 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
MBG, Не верю я в чудеса. Вечером соберу эскулайт. А то непорядок, оракл - есть, mssql - есть, access- есть, sybase sa - есть, fb - есть, даже Hytech завалялся, а вот самого быстрого sqlite (собранного) - нету. Безобразие ! ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 16:19 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
SiemarglMBG, Не верю я в чудеса. Вечером соберу эскулайт. А то непорядок, оракл - есть, mssql - есть, access- есть, sybase sa - есть, fb - есть, даже Hytech завалялся, а вот самого быстрого sqlite (собранного) - нету. Безобразие ! Это разве чудеса. Вот токиокабинет, по тестам его автора, вдесятеро эскулайт обгоняет на чтении :-) А вставки выполняет почти с той же скоростью, что и выборки :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 16:30 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
А что же тогда форум не переименовать в Tokyo Cabinet, не забыть про этот тормозной SQLite, и не переключить весь код на Tokyo Cabinet ? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 16:56 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
Dmitry ArefievА что же тогда форум не переименовать в Tokyo Cabinet, не забыть про этот тормозной SQLite, и не переключить весь код на Tokyo Cabinet ? Если на движке токиокабинет сделать реляционную СУБД, то преимущества в скорости пропадут. Но тестовую реализацию от Siemargl вполне разумно сравнивать как раз с токиокабинет, а не эскулайт - и тогда явно видно, что буст сделан паршивенько, ибо как раз в таком тесте решение без sql, транзакционности, проверки целостности и проч. просто обязано обогнать эскулайт. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 17:05 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
Повозился блин, с dll-кой и кодировкой. Итого получаем: Комплексный ключ 15.6-0ms vs 0.04ms Простой индекс 171-230ms vs 122ms И 25 минут на создание базы с индексами =) Использование памяти 32М+772Мб база vs 1100Mb RAM В общем выгоды на поиске мало, выигрыш только на создании базы - где дисковые операции. логEnter SQL statements terminated with a ";" sqlite> .load tablefunc.dll sqlite> .timer ON sqlite> pragma page_size; 1024 CPU Time: user 0.000000 sys 0.000000 sqlite> pragma page_size = 4096; CPU Time: user 0.000000 sys 0.000000 sqlite> pragma page_size; 4096 CPU Time: user 0.000000 sys 0.000000 sqlite> pragma cache_size; 2000 CPU Time: user 0.000000 sys 0.000000 sqlite> pragma cache_size = 400000; CPU Time: user 0.000000 sys 0.000000 sqlite> pragma cache_size; 400000 CPU Time: user 0.000000 sys 0.000000 sqlite> create temp table tmp_facts(rowid int); CPU Time: user 0.000000 sys 0.000000 sqlite> select intrange2table (1,10000000,1,'tmp_facts'); CPU Time: user 112.788723 sys 430.500360 sqlite> create table facts(a1 int,a2 int,a3 int,a4 int); CPU Time: user 0.000000 sys 0.000000 sqlite> insert into facts ...> select ...> cast(abs(random())/9223372036854775807.*18 as int), ...> cast(abs(random())/9223372036854775807.*18 as int), ...> cast(abs(random())/9223372036854775807.*18 as int), ...> cast(abs(random())/9223372036854775807.*18 as int) ...> from tmp_facts; CPU Time: user 42.713074 sys 1.185608 sqlite> create index facts_a1_idx on facts(a1); CPU Time: user 68.624840 sys 0.702005 sqlite> create index facts_a3_idx on facts(a3); CPU Time: user 68.250438 sys 0.530403 sqlite> create index facts_a2_idx on facts(a2); CPU Time: user 68.702840 sys 0.514803 sqlite> create index facts_a4_idx on facts(a4); CPU Time: user 67.127230 sys 0.577204 sqlite> select count(*) from facts where a1=2 and a2=2 and a3=2 and a4=2; 112 CPU Time: user 1.138807 sys 0.000000 sqlite> select count(*) from facts where a1=2; 555739 CPU Time: user 0.171601 sys 0.000000 sqlite> select count(*) from facts where a1=2; 555739 CPU Time: user 0.234002 sys 0.000000 sqlite> select count(*) from facts where a1=2; 555739 CPU Time: user 0.280802 sys 0.000000 sqlite> select count(*) from facts where a1=2; 555739 CPU Time: user 0.171601 sys 0.000000 sqlite> create index facts_complex_idx on facts(a1,a2,a3,a4); CPU Time: user 97.765827 sys 1.092007 sqlite> select count(*) from facts indexed by facts_a1_idx where a1=2; 555739 sqlite> select count(*) from facts where a1=2 and a2=2 and a3=2 and a4=2; 112 CPU Time: user 0.015600 sys 0.000000 sqlite> select count(*) from facts where a1=2 and a2=2 and a3=2 and a4=2; 112 CPU Time: user 0.000000 sys 0.000000 ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 20:32 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
И может чего выиграется при фетче данных из базы. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 20:32 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
Siemargl, Код: plaintext 1. 2. 3. 4. 5.
Здесь первый результат не показателен - видно операционка чем-то своим была занята. Если выполните этот запрос несколько раз, убедитесь сами. Собственно, за то и ценю эскулайт, что он замечательно работает с дисковыми базами - когда размер БД и, особенно, выборок, превышает размер ОЗУ, это критично. А вот вставка данных - ахиллесова пята, при наличии нескольких индексов и больших таблицах скорость вставки деградирует сильно (у меня в блоге есть тесты на этот счет, если интересно). Для индекса по паре полей (число+дата, к примеру) разумно ограничиться размером таблицы около 100М записей. Плюс стараться выполнять модифицирующие операции в пакетном режиме. Так что за все приходится платить, "серебряной пули" нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2010, 21:26 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
MBG, протестил я токиокабинет. думал, вот оно, то что мне надо, когда встретил их "рекламу":) В результате, эта хрень вообще не может работать с большим объемом данных. Если ничего не тюнить, то начинает тормозить уже на 100000 записей, причем время вставки растет явно быстрее чем линейно, скорее экспоненциально. Потрахавшись с настройками, выделив здоровый кеш и размер bucket'a в b-дереве, удалось затолкать туда 23 миллиона записей, дальше не реально. Короче, работает она только до тех пор, пока структуры данных в память помещаются. При этом, никакой гарантии целостности данных: отрывок из "tcbdb.h" Код: plaintext 1. 2. 3. 4. 5. 6. 7.
В общем, дерьмо. Моя собственная поделка и то лучше работает на объемах в 10 раз больших. Вот еще ссылка на тесты "мега-крутой" токиокабинет: http://www.dmo.ca/blog/benchmarking-hash-databases-on-large-data/ Точно такая же проблема. В общем, никому не рекомендую. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 11:53 |
|
Ньюсфид для крупной соцсети. SQLite?
|
|||
---|---|---|---|
#18+
Результаты тестов для хэшей мне кажутся невероятными - такая ситуация типична для b-tree, но не для хэшей. Плюс не сделано даже попытки пообщаться с автором токиокабинет, что опять же не внушает доверия. Кстати, для CDB существует обертка, позволяющая модифицировать CDB-базы, а не только как константные использовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2010, 12:46 |
|
|
start [/forum/topic.php?fid=54&msg=36541174&tid=2009361]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
67ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
others: | 327ms |
total: | 495ms |
0 / 0 |