|
|
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
Есть таблица участников - Users. В ней, есессно, участники. И для каждого участника надо хранить данные для построения графиков. Решил хранить графики в XML. Поле total_credit_xml xml Код: xml 1. 2. 3. 4. 5. 6. 7. 8. Клиентское приложение достаёт из базы total_credit_xml и строит график. Всё бы ничего, да когда число участников увеличивается размеры таблиц и сама база сильно растёт. :( При числе участников в 300 тыс. размер базы увеличивается до 40-50 гигабайт. Соответвственно, показ участников в виде таблицы, со всякими join-нами тоже тормозит. Задержки в выводе страниц на экран становятся 3-4 секунды. :( В общем, изобретать велосипед не хочется. Посоветуйте что-нибудь. Или поделитесь, пожалуйста, опытом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2012, 20:06 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValПри числе участников в 300 тыс. размер базы увеличивается до 40-50 гигабайт. Соответвственно, показ участников в виде таблицы, со всякими join-нами тоже тормозит. Задержки в выводе страниц на экран становятся 3-4 секунды. :( А можно пример - как выглядит экран, на который выведены 300 тысяч графиков?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2012, 20:14 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 Dimitry Sibiryakov : Можно: http://stats.boinc.ru/stats/ShowProject.aspx?pr_name=Sat (минут через 10 перегенерю на сегодняшнее число и будут доступны участники, команды, компьютеры..) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2012, 20:22 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValМожно: И что из этого тормозит? У меня страница открылась мгновенно. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2012, 20:30 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 Dimitry Sibiryakov : Дмитрий, сейчас показана только статистика Российского проекта SAT@home. Это маленький проект. Размер базы всего 400 мегабайт. - число участников всего 2488. Но есть и другие проеты, например Seti@home или Einstein@home. С числом участников в 300-400 тысяч и числом компьютеров 1-3 миллиона(для компиков - тоже графики). Вот для них базы и получаются в 40-50 гигабайт. ****** Может xml графики компрессировать перед засовыванием в базу ? А при вынимании декомпрессировать ? (тогда хранить их как как varbinary) Вот я и интересуюсь, кто как хранит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2012, 20:51 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
Наверное, надо определить сначала, где именно тормозит. Разделить процесс на этапы, и смотреть каждый этап за какое время выполняется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2012, 23:51 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
ТС, а в какой БД XML хранишь? Она умеет с XML по особому обращаться? И второе: данные у тебя старые не меняются, только дополняются новые. Храни просчитанные агрегаты,у тебя же запросы даже не меняются ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 00:40 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
АнатоЛойа в какой БД XML хранишь? - Микрософт SQL Server. АнатоЛойОна умеет с XML по особому обращаться? - я не очень понимаю, что значит по-особому. :( И второе: данные у тебя старые не меняются, только дополняются новые. Храни просчитанные агрегаты,у тебя же запросы даже не меняются АнатоЛой , я чего-то не понимаю. При каждом обновленлии статистики графики пересчитываются. Да они совсем простые, типа день/значение за 2 месяца. (DateTime/Int64) А что такое просчитанные агрегаты ??? S.G. Наверное, надо определить сначала, где именно тормозит. - так это видно. Тормозит SQL Server. При размере базы в 40-50 гигабайт он долго читает с диска. Даже при простых запросах, типа select COUNT(*) from Users where total_credit > 100 задержка в 1-2 секунды. ***** Сейчас посмотрел: Несжатый график - 5 KBytes. Сжатый в Base64String - 600 bytes. Интересно, а MS SQL 2008 умеет сжимать данные ? типа zip/upzip ? Мож ему где-то галочку поставить, чтобы это поле сжимал ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 09:40 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
Умеет ли СУБД использовать XML-файл не просто как файл, который отдаёт клиенту, а выполнять над ним более сложные действия на стороне сервера: строить индексы по внутреннему содержимому XML, использовать XPath для запросов к содержимому XML, ... [quot SerVal] АнатоЛойИ второе: данные у тебя старые не меняются, только дополняются новые. Храни просчитанные агрегаты,у тебя же запросы даже не меняются АнатоЛой , я чего-то не понимаю. При каждом обновленлии статистики графики пересчитываются. Да они совсем простые, типа день/значение за 2 месяца. (DateTime/Int64) А что такое просчитанные агрегаты ??? Если данные настолько простые , зачем используешь XML? Ложи в простую таблицу. Просчитанные агрегаты: это промежуточные результаты, которые рассчитываются на основании исходных (первичных) данных, сохраняются как дополнительная информация в БД и используется в дальнейших расчётах, чтобы ускорить/облегчить расчёт новых данных. У тебя текущие значения на твоих графиках всегда можно посчитать как: суммарное значение, которые было вчера + сумма значений, котоорые поступили сегодня. Сегодня посчитал: сохрани число и дату/время. Завтра будешь считать: возьми вчерашний расчёт, добавь к нему свежие данные, и снова сохрани. Делов-то... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 10:50 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
АнатоЛойУмеет ли СУБД использовать XML-файл не просто как файл, который отдаёт клиенту, а выполнять над ним более сложные действия на стороне сервера: строить индексы по внутреннему содержимому XML, использовать XPath для запросов к содержимому XML, ... - умеет. А зачем базе что-то делать с графиками ? На стороне клиента(обновителя статистики) это намного быстрее. АнатоЛойЕсли данные настолько простые, зачем используешь XML? Ложи в простую таблицу. Что-то я никак не пойму.. У каждого участника 9 разных графиков. У каждой команды, страны и компьютера - тоже по 9 графиков. В какие таблицы их ложить ? АнатоЛойСегодня посчитал: сохрани число и дату/время. Завтра будешь считать: возьми вчерашний расчёт, добавь к нему свежие данные, и снова сохрани. Делов-то... Так оно так и делается. Предыдущий график используется для расчёта следующего. В каждый график ежедневно добавляется дневное значение. Самый старый день удаляется. Поэтому в графике всегда 60 значений(дата/время и значение). ..наверное, я чего-то не понимаю. :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 11:15 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValЧто-то я никак не пойму.. У каждого участника 9 разных графиков. У каждой команды, страны и компьютера - тоже по 9 графиков. В какие таблицы их ложить ?в одну простую таблицу: Код: plaintext 1. 2. 3. Всё. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 11:25 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
Ну ещё поле graphid, раз графиков у юзера может быть несколько. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 11:26 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValS.G. Наверное, надо определить сначала, где именно тормозит. - так это видно. Тормозит SQL Server. При размере базы в 40-50 гигабайт он долго читает с диска. Даже при простых запросах, типа select COUNT(*) from Users where total_credit > 100 задержка в 1-2 секунды. ну, отсюда не видно, где тормозит. Еще например, я не понял, xml - их много, по одному на каждого участника, или один за всех? И почему был выбран xml? В программне было что-то готовое для отображения xml, или просто так? В принципе данные для графика хорошо держать просто в базе (как уже подсказали). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 11:35 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
On 08/07/2012 09:51 PM, SerVal wrote: > Может xml графики компрессировать перед засовыванием в базу ? А при вынимании > декомпрессировать ? > (тогда хранить их как как varbinary) Тоже хорошая идея. Если они достаточно большие. Если маленькие, то не будет эффекта уменьшения --в архивах заголовки всякие есть. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 12:14 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
On 08/07/2012 09:06 PM, SerVal wrote:> Есть таблица участников - Users. В ней, есессно, участники. И для каждого > участника надо хранить данные для построения графиков. > Решил хранить графики в XML. > > Поле total_credit_xml xml > > <chart> > <title>Total Credit</title> > <values> > <x_value>09.06.2012</x_value> > <y_value>0</y_value> > </values> > .. > </chart> > > > > Клиентское приложение достаёт из базы total_credit_xml и строит график. Нормальное вполне решение. > > Всё бы ничего, да когда число участников увеличивается размеры таблиц и сама > база сильно растёт. :( > При числе участников в 300 тыс. размер базы увеличивается до 40-50 гигабайт. 300 тыщ -- маленькая таблица. > Соответвственно, показ участников в виде таблицы, со всякими join-нами тоже > тормозит. Задержки в выводе страниц на экран становятся 3-4 секунды. :( Это не изза этого. По другим причинам. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 12:15 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
> - так это видно. Тормозит SQL Server. При размере базы в 40-50 гигабайт он долго > читает с диска. > Даже при простых запросах, типа select COUNT(*) from Users where total_credit > > 100 задержка в 1-2 секунды. Это по другим причинам. Ты видимо не представляешь, где простой запрос, а где сложный, так что не рассуждай, а шли уже конкретный тормозящий запрос с описанием таблиц. А к решению о том, как хранить графики, это не относится. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 12:18 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
1. Использовать не XML а бинарную серилизацию в блоб - XML избыточен - мало того, что теги, да еще и числа представленны неэффектино. 2. "Соответвственно, показ участников в виде таблицы, со всякими join-нами тоже тормозит" - если в этом показе не используется XML и при этом тормозит, это странно - по идее длинные поля - "out of row" и не должны сильно влиять на селекты, если они ими не используется (на сервер, надеюсь не уходит select * from table?) в MS SQL есть спецтип для XML ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 12:27 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 tanglir : авторв одну простую таблицу: myTable ( userid, x, y, graphid ) Всё. Так получится на каждого участника: 9 графиков -> RowCount = 9*60 дней. = 530 записей. На 300 тыс. участников соответственно -> 300тыс*530= 159 000 000 (159 миллионов записей в таблице) Из 150 милионов записей я ещё не выбирал, но подозреваю, что выборка типа select x, y, graphid from myTable where userid= @userid может оказаться не очень быстрой. ************* 2 S.G. : S.G.не понял, xml - их много, по одному на каждого участника У каждого участника - по 9 xml графиков: total_credit_xml, average_credit_xml ... 2 MasterZiv : xml поля сжимаются с 5 KB до 600 байт(varchar). В ближайшее время попробую. Ты видимо не представляешь, где простой запрос, а где сложный.. Это сложный запрос: select count(*) from Users where total_credit >100 order by total_credit desc ? Я проверил в SQL-studio: запрос длится 2-3 секунды(если юзеров >=300 тыс.) ****** 2 F# : авторесли в этом показе не используется XML.. - ну как это не используются ? Графики участника должны же показыватся. Вот как здесь: Участник _2e_ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 13:03 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 F# : F#1. Использовать не XML а бинарную серилизацию в блоб - XML избыточен Надо признаться, я не знаю, что такое блоб . Это varbinary(max) ? "Бинарная серилизация в блоб".. как-то я плохо себе представляю что это такое. :( А при этой "бинарной серилизации в блоб" размер сохраняемых данных уменьшится ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 13:18 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerVal, авторРешил хранить графики в XML. дата - допустим, 8 байт (или 3 байта date в сиквеле2008) значение - допустим, 8 байт (или 16, не важно) автор<chart> <title>Total Credit</title> <values> <x_value>09.06.2012</x_value> <y_value>0</y_value> </values> ... </chart> ??? я действительно не понимаю чем обосновано решение. сэкономил на адски большой но идеально узкой табличке с точками? то что эти точки теперь занимают: дата - 28 байт значение - 20-30 байт это типа экономия? или высока вероятность появления чего-то кроме X-Y? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 13:26 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValИз 150 милионов записей я ещё не выбирал, но подозреваю, что выборка типа select x, y, graphid from myTable where userid= @userid может оказаться не очень быстрой.А вы не подозревайте, а про индексы почитайте для начала. Когда поймёте, что такое селективность, какова она у поля "юзер" в вашем запросе и при чём тут индексы - велкам бэк. Впрочем, к тому времени подобные вопросы у вас уже пропадут :) SerValЭто сложный запрос: select count(*) from Users where total_credit >100 order by total_credit desc ? Я проверил в SQL-studio: запрос длится 2-3 секунды(если юзеров >=300 тыс.)Угу, сложный, аж жуть. Если индекса по "тотал_кредит" нету. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 13:35 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
tanglirв вашем запросев данных, если точнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 13:35 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 tanglir : авторА вы не подозревайте, а про индексы почитайте для начала. ..Если индекса по "тотал_кредит" нету. Ну как это нету ??? Есессно. есть. Без индексов никак нельзя. Однако ж, это такая простая и сама собой подразумевающаяся вещь, что я и писать не стал. О них и так все знают. (пожалуй, единственная проблема с индексами - это их дефрагментация после DBCC SHRINKDATABASE..) И констрансы на таблицы почти все убрал. Проверяю перед select и update вручную. Так быстрее(хоть и менее надёжно). Но об этом-то что писать ? Это тоже все знают. ***** Решил пока сжимать xml-ки в Base64String и хранить в базе как varchar(1000). Вечером буду переделывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 13:58 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 Решил хранить : Ну Вы подскажите идею, как и в каком виде хранить двухмесячные значения x, y ? ( DateTime и Int64 соответственно ). Я ж не против всё переделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 14:04 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
MasterZivЭто не изза этого. По другим причинам. +1. ТС, ищи узкое место в своём процессе: из какиз действий он состоит, сколько они по отдельности длятся, почему, как улучшить действие либо процесс в целом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 17:38 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValЭто сложный запрос: select count(*) from Users where total_credit >100 order by total_credit desc ? Я проверил в SQL-studio: запрос длится 2-3 секунды(если юзеров >=300 тыс.) Бред какой-то. Ведь этот запрос вернет одну строку, с указанием количества юзеров, у которых total_credit >100. Зачем тогда order by, да еще desc? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 18:05 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
Cane Cat Fisher, интересно, что показывает эксплейн этого запроса :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 18:20 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
АнатоЛойищи узкое место в своём процессе: из каких действий он состоит Сейчас речь об SQL сервере, а не о клиентской программе. Вот сижу в Menegement Studio и набиваю: select top(10) * from Users where total_credit>100 order by total_credit desc go И всё замечательно, пока размер базы небольшой. А когда размер 40-50 гигабайт - задержка 2-3-5 секунд. :( Никаких процессов больше нет. В каком процессе искать узкое место ? Попробую поизменять индексы. Опыт в составлении индексов у меня небольшой( мягко говоря). Хотя я всё равно думаю, что тормозит потому, что размер базы большой. p.s. Переделываю под хранение сжатых xml. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 18:25 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 Cane Cat Fisher : Cane Cat FisherБред какой-то. Ведь этот запрос вернет одну строку Ну ошибся я в качестве примера.(count тут не причём). ***** Напугали меня. Понаделал кучу индексов на таблицы... начались блокировки при insert-ах. :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 18:29 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValselect top(10) * from Users where total_credit>100 order by total_credit desc go От БД не нужно требовать всегда быстро выдавать результат на любой запрос. Проверяй на скорость выполнения те запросы, которые будет выполнять твоё приложение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 18:37 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValНапугали меня. Понаделал кучу индексов на таблицы... начались блокировки при insert-ах. :( Потому что индексы надо создавать с умом, а не от балды. EXPLAIN тут уже упомянули. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 18:50 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 АнатоЛой : АнатоЛойПроверяй на скорость выполнения те запросы, которые будет выполнять твоё приложение. - так оно и будет выполнять именно такой запрос. 2 Dimitry Sibiryakov : Ну если Вы разбираетесь, подскажите какие индексы создать для Users ? (таблицы Команд, Стран - такие же. Там я сам.. без ума, но по образу и подобию, так сказать..) Код: sql 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 19:26 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
On 08/08/2012 07:25 PM, SerVal wrote: > select top(10) * from Users where total_credit>100 order by total_credit desc > go Ты хочешь поговорить о производительности этого запроса ? Тебе это нужно ? > > И всё замечательно, пока размер базы небольшой. А когда размер 40-50 гигабайт - > задержка 2-3-5 секунд. :( А индекс на total_credit есть? А записей всего и с total_credit>100 сколько ? > Хотя я всё равно думаю, что тормозит потому, что размер базы большой. Т.е. по-твоему только с маленькими базами данных можно работать, да? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 19:46 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValподскажите какие индексы создать для Users ? Это зависит от данных в этой таблице и запросов к ней. Какой процент записей в ней имеет total_credit>100? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 19:46 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
On 08/08/2012 08:26 PM, SerVal wrote: > 2 *Dimitry Sibiryakov*: > Ну если Вы разбираетесь, подскажите какие индексы создать для Users ? А это ещё немного зависит от того, какие запросы ты будешь выполнять, не правда ли ? > (таблицы Команд, Стран - такие же. Там я сам.. без ума, но по образу и подобию, > так сказать..) Ага, такие же. В них поля и в полях данные ... Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 19:48 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
MasterZivТы хочешь поговорить о производительности этого запроса ? Тебе это нужно ? Да. Хочется, чтобы этот запрос выполнялся не 3-5 секунд, а побыстрее. Но это можно и потом, когда загрузку/обновление удастся сделать побыстрее. ******* Ребятки, я уже написал, что вопрос о производительности клиентского приложения пока не актуален. Сейчас бы просто уменьшить время загрузки/обновления статистики и разрастание таблиц из-за графиков. Графики XML стал хранить сжатыми, как varchar(1000)/ Но всё равно, производительность не радует, потому что обновлять надо каждый день. Пока запустил обновление, чтобы посмотреть - дала-ли что-нибудь компрессия графиков. Download stats started 08 Aug 2012 15:57:39. Einstein@Home: началась загрузка данных. Einstein@Home: запущено 17 нитей добавления 324562 участников в таблицу Users Einstein@Home: запущено 67 нитей добавления 2668084 компьютеров в таблицу Hosts Einstein@Home: запущено 3 нитей добавления 10358 команд в таблицу Teams Einstein@Home: ожидаем обновление участников, команд и компьютеров.... Сижу жду окончания процесса. Потом помотрю на время обновления и размер базы. p.s. Убрал пока все индексы кроме как на PRIMARY KEY. Блокировки пропали. (Ура !) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 20:30 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValХочется, чтобы этот запрос выполнялся не 3-5 секунд, а побыстрее. Тогда создай DESCENDING index на total_credit. SerValСейчас бы просто уменьшить время загрузки/обновления статистики и разрастание таблиц из-за графиков. Тогда как уже и сказали: выкинь к ЧМ этот XML и храни данные в реляционных таблицах, как все нормальные люди. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 20:38 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
On 08/08/2012 09:38 PM, Dimitry Sibiryakov wrote: > SerVal > Хочется, чтобы этот запрос выполнялся не 3-5 секунд, а побыстрее. > > > Тогда создай *DESCENDING* index на total_credit. Это всё равно. Индексы могут сканироваться в любую сторону. > Тогда как уже и сказали: выкинь к ЧМ этот XML и храни данные в реляционных > таблицах, как > все нормальные люди. Да это всё равно как хранить. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 23:08 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValВот сижу в Menegement Studio и набиваю: select top(10) * from Users where total_credit>100 order by total_credit desc go И всё замечательно, пока размер базы небольшой. А когда размер 40-50 гигабайт - задержка 2-3-5 секунд. :( а у этого запроса есть план выполнения, или как оно там называется в mssql-e? нечто, показывающее используемые индексы, время и прочее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 23:09 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 Dimitry Sibiryakov : То есть Вы предлагаете создать дополнительную таблицу, где на каждого участника будет 17*60= 1020 записей ? (17 графиков по 60 значений в каждом). Итого, для 300 тыс. участников в таблице будет 300 тыс.* 1020 = 306 000 000 (306 миллионов записей) Я правильно понял ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 23:13 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 S.G.: а у этого запроса есть план выполнения, или как оно там называется в mssql-e? Конкретно этот запрос имеет мало значения. Он слишком прост. Меня интересует время выборки для таких простыз запросов. Если такой примитив даёт задержку в 2-3 секунды, то рассматривать что-либо сложнее я не вижу смысла. Вот, например stored proc, выводящая участников на экран по 100 штук: Код: sql 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. Выполняется быстро, поскольку постраничный вывод для листания в GridView. Но я ещё раз говорю, это пока рано рассматривать и анализировать. ***** Завершилась загрузка пустой базы(console log): >ProjectStatsDownloader.exe Download stats started 08 Aug 2012 15:57:39. Einstein@Home: началась загрузка данных. Einstein@Home: запущено 17 нитей добавления 324562 участников в таблицу Users Einstein@Home: запущено 67 нитей добавления 2668084 компьютеров в таблицу Hosts Einstein@Home: запущено 3 нитей добавления 10358 команд в таблицу Teams Einstein@Home: ожидаем обновление участников, команд и компьютеров. Einstein@Home: обновление команд завершено за 21 минут 54 секунд. Einstein@Home: обновление участников завершено за 48 минут 5 секунд. Einstein@Home: обновление компьютеров завершено за 1 часов 25 минут 36 секунд. Einstein@Home: вычисление рангов команд и число участников в них завершено за 22 секунд. Einstein@Home: вычисление рангов участников завершено за 9 минут 16 секунд. Einstein@Home: вычисление рангов участников в команде и в стране завершено за 31 минут 39 секунд. Einstein@Home: вычисление рангов компьютеров завершено за 1 часов 14 минут 28 секунд. Einstein@Home: Вычисление рангов стран завершено за 3 минут 31 секунд. Einstein@Home: таблица Project обновлена. Einstein@Home: Обновление завершено за 3 часов 25 минут 37 секунд. Загрузка и обновление проектов завершена. Продолжительность: 3 часов 25 минут 37 секунд. > Размер базы из-за компрессии графиков уменьшился с 48 до 24 GB MB. Уже на много лучше. Однако продолжительность в 3 часов 25 минут 37 секунд. .. как-то не очень. :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 23:37 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValИтого, для 300 тыс. участников в таблице будет 300 тыс.* 1020 = 306 000 000 (306 миллионов записей) Я правильно понял ? Да. Сейчас у тебя те же миллионы записей запиханы в формат, который делает добавление и удаление значений очень медленным. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 23:44 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
MasterZivИндексы могут сканироваться в любую сторону. Тогда откуда 3 секунды на индексную выборку десяти записей? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2012, 23:45 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
> Конкретно этот запрос имеет мало значения. Он слишком прост. > Меня интересует время выборки для таких простыз запросов. Понятия "такие простые запросы" не существует. Каждый запрос конкретен, выполняется на конкретных данных и обладает конкретной производительностью, обобщать тут не имеет никакого смысла. > Если такой примитив даёт задержку в 2-3 секунды, то рассматривать что-либо > сложнее я не вижу смысла. А с чего ты взял, что это примитивный запрос ? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 01:10 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
On 08/08/2012 08:26 PM, SerVal wrote: > CREATE TABLE dbo.Users( > -- графики -- > [total_credit_xml] [varchar](1000) NULL, > [expavg_credit_xml] [varchar](1000) NULL, > [credit_day_xml] [varchar](1000) NULL, > [credit_week_xml] [varchar](1000) NULL, > [credit_month_xml] [varchar](1000) NULL, > [project_rank_xml] [varchar](1000) NULL, > [project_rank_day_xml] [varchar](1000) NULL, > [project_rank_week_xml] [varchar](1000) NULL, > [project_rank_month_xml] [varchar](1000) NULL, > [team_rank_xml] [varchar](1000) NULL, > [team_rank_day_xml] [varchar](1000) NULL, > [team_rank_week_xml] [varchar](1000) NULL, > [team_rank_month_xml] [varchar](1000) NULL, > [country_rank_xml] [varchar](1000) NULL, > [country_rank_day_xml] [varchar](1000) NULL, > [country_rank_week_xml] [varchar](1000) NULL, > [country_rank_month_xml] [varchar](1000) NULL > ) Кстати, нарушение 1НФ хоть поздно, но detected. Лучше поздно, чем никогда. Так что выноси это всё в отдельную дочернюю таблицу. О трёх полях. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 01:14 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
On 08/09/2012 12:45 AM, Dimitry Sibiryakov wrote: > Тогда откуда 3 секунды на индексную выборку десяти записей? Почему обязательно на индексную ? Я как-то не просёк, что автор уже успел создать индекс нужный. Или сообщить, что индекс уже был создан ранее. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 01:16 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 Dimitry Sibiryakov : Dimitry SibiryakovДа. Сейчас у тебя те же миллионы записей запиханы в формат, который делает добавление и удаление значений очень медленным. Я почему-то думаю, что insert/delete в 300 миллионнной таблице будет ещё медленнее. К тому же, получение от SQL сервера varchar(1000) и преобразование в Byte Array делается намного быстрее, чем выборка 60-ти записей. А в клиентском запросе будет надо будет присоединять графики из таблицы в 300 миллионов записей( join по user_id). Признаться, выборка из 300 миллионов записей меня тоже пугает. 2 MasterZiv : MasterZivА с чего ты взял, что это примитивный запрос ? Так в этом запросе ничего нету. Отсутствуют join, group by, intersect, distinct, between итд.. В общем выше я привёл пример запроса чуть-чуть посложнее. ***** Сейчас думаю.. может совсем освободить таблицу Users от графиков ? Все графики - в таблицу UserXml. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Тогда таблица Users пухнуть не будет. И выборка списка участников из неё ускорится. А когда надо графики на странице - джойнить участника с его графиками по @id ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 01:35 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 MasterZiv : MasterZivКстати, нарушение 1НФ хоть поздно, но detected. Какое нарушение ? Что такое 1НФ я не знаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 01:39 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
On 08/09/2012 02:39 AM, SerVal wrote: > Какое нарушение ? Что такое 1НФ я не знаю. Это и так понятно, что не знаешь. Узнавай. Хотя бы в википедии прочитай "1-ая нормальная форма". Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 01:58 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
Код: sql 1. 2. 3. MasterZivХотя бы в википедии прочитай "1-ая нормальная форма". Почитал. И в чём же здесь нарушение ? В том что графики участника в его-же таблице ? Вообще-то, они являются неотемлемым атрибутом участника. И при перемещении их в друную таблицу они должны быть связаны с участником череp FOREIGN KEY. (теоретически). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 02:21 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerVal2 S.G.: а у этого запроса есть план выполнения, или как оно там называется в mssql-e? Конкретно этот запрос имеет мало значения. Он слишком прост. Меня интересует время выборки для таких простыз запросов. Если такой примитив даёт задержку в 2-3 секунды, то рассматривать что-либо сложнее я не вижу смысла.Я по прежнему не вижу ничего, показывающее план выполнения, использование индексов. Только какие-то 2-3 секунды, измеренные- чем, часами? SerValРазмер базы из-за компрессии графиков уменьшился с 48 до 24 GB MB. Уже на много лучше. Однако продолжительность в 3 часов 25 минут 37 секунд. .. как-то не очень. :(Уменьшилось время передачи данных от сервера к клиентской программе, из-за компрессии (меньше данных передается). Увеличилось время обработки данных из-за компрессии-декомпрессии. По прежнему нет понимания, что надо рассмотреть несколько этапов обработки данных - выборка, передача, обработка в клиентской программе (а также анализировать каждый из пунктов в отдельности) и смотреть куда уходит время. и еще раз - размер БД и скорость выборки имеют весьма малую зависимость, если конечно бд построена правильно и не тянуть все на клиента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 03:57 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
Так все данные у клиента. Клиентская программа только впихивает данные SQL серверу. Выбирать пока нечего. А чтобы быстрее впихнуть, графики она компрессирует. 17 нитей впихивают 324562 участника в таблицу Users (по 20 тысяч каждая нить). Самым простым INSERT-ом безо всяких условий. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Больше ничего. Какой тут может быть план ? Индексирован сейчас только PRIMARY KEY. И что тут рассматривать? - Statistics for INDEX 'PK__Users__3213E83F1CFC3D38'. ? Все 17 нитей фактически простаивают, потому как медленнные диски не дают SQL серверу записать данные. Загрузка процессоров клиентской программой - max 25%. SQL сервером - 10-15%. И всё это из-за размера файлов базы. Лампочка диска горит не переставая. Всё время уходит в ожидание записи на диск 5-и гигабайт данных. То же самое и при тупом UPDATE. Вот вставка в пустую базу: Einstein@Home: обновление участников завершено за 48 минут. Einstein@Home: обновление компьютеров завершено за 1 часов 25 минут. Все остальные вычисления занимают ничтожное время.(для них, действительно, надо создать индексы и смотреть execution plan). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 05:19 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValЯ почему-то думаю"Мне говорят, что так будет лучше, но я думаю наоборот". Зачем тогда спрашивать? SerValВсе 17 нитей фактически простаивают, потому как медленнные диски не дают SQL серверу записать данные. И зачем тогда было спрашивать о производительности селект-запроса, если основной затык вовсе не в этом запросе, а в совершенно другой задаче - задаче быстрой записи 5Гб ненормализованных данных?? ЗЫ. Не пробовали через bulk insert (или как оно там в мсскл называется) эти же 5 Гб залить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 05:50 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 tanglir : tanglirЗачем тогда спрашивать? Я спрашивал как зранить графики, чтобы они меньше места занимали. Лучше - это когда на диск меньше пишется/читается. Потому как простой запрос select count(*) from Hosts вызывает шмурыгание диска на 3-4 секунды. Ну какие тут индексы нужны ? Или Execution Plan ? (я больше таким селестом не пользуюсь). Я уж думал поставить базы на диск с компрессией данных, да чего-то опасюсь. ***** tanglirНе пробовали через bulk insert (или как оно там в мсскл называется) эти же 5 Гб залить? Не. Входные данные сырые и кривые. Проверять надо. Сейчас переделываю: переношу графики - в другую таблицу. Формат прежний - compressed xml. ***** Ребятки, спасибо за отклики и участие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 06:36 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
On 08/09/2012 03:21 AM, SerVal wrote: > Почитал. И в чём же здесь нарушение ? В том что графики участника в его-же таблице ? Нет, в том, что их МНОГО в одной таблице. > Вообще-то, они являются неотемлемым атрибутом участника. И при перемещении их в > друную таблицу они должны быть связаны с участником череp FOREIGN KEY. > (теоретически). Ну да. Соображаешь. Ещё сообрази, как выстроить PK этой таблицы, и будет всё ОК. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 09:11 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
> Больше ничего. Какой тут может быть план ? Индексирован сейчас только PRIMARY KEY. > И что тут рассматривать? - Statistics for INDEX 'PK__Users__3213E83F1CFC3D38'. ? План. Брать и рассматривать. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 09:13 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
On 08/09/2012 06:50 AM, tanglir wrote: > ЗЫ. Не пробовали через bulk insert (или как оно там в мсскл называется) эти же 5 > Гб залить? bulk copy utility, bulk copy routines. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 09:14 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
On 08/09/2012 07:36 AM, SerVal wrote: > Я уж думал поставить базы на диск с компрессией данных, да чего-то опасюсь. Не надо. > Не. Входные данные сырые и кривые. Проверять надо. Проверяй, а потом запихивай в bulk, кто ж мешает? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 09:16 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 MasterZiv : MasterZivПроверяй, а потом запихивай в bulk, кто ж мешает? Ну что Вы в самом деле.. как это ""запихивай в bulk" ? Мне ж надо сравнивать вчерашние и вновь полученные данные. Вчерашние-то куда ? В "бульк" уйдут ? И что я сравнивать буду ??? И ещё: в полученных данных полно, например, участников без имени. Нам такие товарищи в статистике не нужны. Запихиваем его в таблицу InvalidReceivedUser и продолжаем добавлять хороших в таблицу Users. ***** Я смотрю сейчас на секционированные таблицы. Может можно новые данные загружать в новые секции. А потом сравнить новое и старое, построить графики.. После чего убить старую секцию и нарезать ещё одну новую для нового дня.. итд. Не знаю, правда, не слишком ли это сложно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 10:23 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerVal, в общем, нужно переделать на: 1. таблица Users - данные только об участниках (id,code,name,description) 2. таблица графиков - [dbo].[Charts_Xml] структура (User_ID INT, TypeChart INT, Value XML) где TypeChart - тип графика + create nonclustered index IX_UserChart_Charts_Xml on Charts_Xml(User_ID, TypeChart) всё будет летать и про Нормальные формы почитай - интересно будет, (1НФ 2НФ 3 НФ)... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 11:09 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
ну чтоб поменьше "переделывать" - Value можешь пока оставить как varchar(1000) или что там у тебя ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 11:11 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValЯ спрашивал как зранить графики, чтобы они меньше места занимали. С этой точки зрения XML - наихудшее решение, даже сжатый, поскольку у него КПД (отношение полезных байт к мусорной обвеске) - считанные проценты. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 11:38 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 доброжелатель!!!! Спасибо. Я примерно так уже переделываю. Скорости это не прибавит(при нынешней структуре программы). Но уже позволит не меняя таблицы Users, добавлять/удалять графики c меньшими затратами. ***** А про нормальные формы уже почитал. Я советы не игнорирую, в какой бы форме они ни были высказаны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 11:41 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
On 08/09/2012 12:38 PM, Dimitry Sibiryakov wrote: > С этой точки зрения XML - наихудшее решение, даже сжатый, поскольку у него КПД > (отношение > полезных байт к мусорной обвеске) - считанные проценты. Дима, это копейки всё по сравнению с остальными проблемами. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 12:16 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
On 08/09/2012 11:23 AM, SerVal wrote: > Ну что Вы в самом деле.. как это ""запихивай в bulk" ? Есть bulk insert API, вызывай его вместо обычного ODBC или что ты там используешь. > Мне ж надо сравнивать вчерашние и вновь полученные данные. Вчерашние-то куда ? В > "бульк" уйдут ? > И что я сравнивать буду ??? Ну не удаляй старые данные, и будет тебе счастье. > Я смотрю сейчас на секционированные таблицы. Может можно новые данные загружать > в новые секции. Ты всё время не туда смотришь, как я посмотрю. Тебе надо 0) видимо переделать структуру БД, нормализовать. 1) оптимизировать конкретные запросы, строя под них индексы. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 12:17 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovSerValЯ спрашивал как зранить графики, чтобы они меньше места занимали. С этой точки зрения XML - наихудшее решение, даже сжатый, поскольку у него КПД (отношение полезных байт к мусорной обвеске) - считанные проценты.+1. SerVal, на пальцах: Код: plaintext 1. 2. 3. 4. 5. 6. 7. iduseridgraphtypexy10050009.06.20120Добавляем 2 (биг)инта: +8(16)байт Убираем xml-евскую шелуху: что-то около -100 байт. PS. оффтоп, но заинтересовало, что означает эта конструкция: Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 12:22 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerVal Клиентская программа только впихивает Сначала проблемы было только с чтением. Потом, оказывается, с "впихиванием". Также мелькнула мысль о том, что надо сравнивать старое и новое. Может быть, надо было еще вначале поднатужиться и дать более полное описание, а не свои идеи велосипеда? В общем, пока что: 1. xml - в топку. 2. Размер - уяснить себе смысл фразы "размер не имеет значения". 3. нормальные формы. MasterZivДима, это копейки всё по сравнению с остальными проблемами. тут одни проблемы :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 12:54 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
MasterZivДима, это копейки всё по сравнению с остальными проблемами. Для хранения и выборки это может быть и копейки, но насколько я понял при добавлении данных аффтар для каждого значения: 1) вытаскивает XML 2) парсит его 3) удаляет старейшее значение 4) добавляет новейшее 5) обратно компонует XML 6) сохраняет. При таком стиле работы я удивляюсь, что он вообще способен дождаться окончания импорта. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 13:09 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
> В общем, пока что: > 1. xml - в топку. Ребята, да чем вам XML-то не угодил ? Я всегда очень против использования XML в RDB, но тут как раз тот случай, когда вполне можно использовать либо XML, либо JSON, да хоть просто текст форматированный. Это обрабатывается только на клиенте. Хочется человеку -- ну и пусть, может у него с той стороны уже (на клиенте) всё под это заточено. > MasterZiv > Дима, это копейки всё по сравнению с остальными проблемами. > > тут одни проблемы :) Согласен. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 13:27 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 MasterZiv : MasterZivЕсть bulk insert API, вызывай его вместо обычного ODBC или что ты там используешь. Ну да, я помню Этот "бульк", он ещё для SQL 2003 был, а может и раньше. Такая примочка к SQL серверу, чтобы он мог с диска C:\ файлы читать. Правда, я никак не пойму 1. отчего "бульк" будет быстрее простейшего INSERT-а. 2. зачам сначала забирать данные в память, проверять, потом опять скидывать на диск, чтобы BCP опять читал их с диска и запихивал в таблицу ? Про ODBC тоже что-то помню. Кажется, это такой старинный драйвер для чего-то. Правда не помню, где он используется и зачем. :( MasterZivУбираем xml-евскую шелуху: что-то около -100 байт. 100 байт на один день. 60 дней со значениями Compressor сжимает до 600 байт в Base64String или 420 bytes в varbinary. 2 S.G. : S.G.Сначала проблемы было только с чтением. Потом, оказывается, с "впихиванием". Ну, я же с самого начала написал, что надо как-то ужать размеры графиков, хранящихся в базе данных. S.G.Также мелькнула мысль о том, что надо сравнивать старое и новое - ну а как же. А из чего же строятся графики за неделю, месяц... ? S.G.3. нормальные формы. Так я не против чего-нибудь нормализовать. Только пока нечего нормализовывать. Скорость тупо зависит от скорости чтения/записи на диск. 2 tanglir : tanglirно заинтересовало, что означает эта конструкция: [stats_update_time] [datetime] NOT NULL DEFAULT (getutcdate()-getutcdate()), Это SQL аналог CPP и C# DateTime.MinValue.(мнимальная дата 1900 год). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 15:01 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValПравда, я никак не пойму <, …> отчего "бульк" будет быстрее простейшего INSERT-а. Оттого, что каждый простейший INSERT — это отдельная транзакция , а «бульк», по идее, должен все данные залить в единственной транзакции . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 15:09 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 Dimitry Sibiryakov : Dimitry SibiryakovДля хранения и выборки это может быть и копейки, но насколько я понял при добавлении данных аффтар для каждого значения: 1) вытаскивает XML 2) парсит его 3) удаляет старейшее значение 4) добавляет новейшее 5) обратно компонует XML 6) сохраняет. При таком стиле работы я удивляюсь, что он вообще способен дождаться окончания импорта. Примерно так. Однако ж я уже писал, что 60 нитей с готовыми INSERT-ами ждут, когда SQL сервер освободится для следущей записи на диск.. Нагрузка на процессор - никакая. Ну и сам SQL сервер тоже ждёт, пока что-то запишется на диск. :( Тут никакие индексы не помогут. Средняя скорость записи SQL сервером на диск ~ 20-40 МБ в секунду. А иногда падает до 10. :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 15:14 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
On 08/09/2012 04:01 PM, SerVal wrote: > 1. отчего "бульк" будет быстрее простейшего INSERT-а. Он нетранзационный. > 2. зачам сначала забирать данные в память, проверять, потом опять скидывать на диск, > чтобы BCP опять читал их с диска и запихивал в таблицу ? Чтобы проверить. К тому же, если ты будешь ипользовать bulk copy API , записывать на диск вовсе не обязательно. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 16:17 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerVal2 Dimitry Sibiryakov : Dimitry SibiryakovДля хранения и выборки это может быть и копейки, но насколько я понял при добавлении данных аффтар для каждого значения: 1) вытаскивает XML ... 6) сохраняет. При таком стиле работы я удивляюсь, что он вообще способен дождаться окончания импорта. Примерно так. Однако ж я уже писал, что 60 нитей с готовыми INSERT-ами ждут, когда SQL сервер освободится для следущей записи на диск.. Нагрузка на процессор - никакая. Ну и сам SQL сервер тоже ждёт, пока что-то запишется на диск. :( Тут никакие индексы не помогут. Средняя скорость записи SQL сервером на диск ~ 20-40 МБ в секунду. А иногда падает до 10. :( Вообще, интересно увидеть план запроса, которым получаете Dimitry Sibiryakov1) вытаскивает XML а все остальное (парсинг, и т.д.) обрабатывается на сервере или на клиенте? И все-же, попробуйте вариант который советовали Вам раньше. Просто, одну табличку. Причем, пока без удаления данных из нее и расчета агрегатов. Залейте в нее данные, добавьте индексы чтобы была высокая селективность, и попробуйте на табличке типичные запросы. Если скорость не устроит, добавить табличку с расчитанными агрегатами. Как писали ранее, размер базы, при правильных индексах, почти не имеет значения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 16:52 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
MasterZiv > В общем, пока что: > 1. xml - в топку. Ребята, да чем вам XML-то не угодил ? Я всегда очень против использования XML в RDB, но тут как раз тот случай, когда вполне можно использовать либо XML, либо JSON, да хоть просто текст форматированный. Это обрабатывается только на клиенте. Хочется человеку -- ну и пусть, может у него с той стороны уже (на клиенте) всё под это заточено. Я вначале не имел ничего против. Вопрос звучал "как хранить" - ну если уже сделано так, пускай хранит в xml. Когда надо, вытащил пару графиков, показал. Но, оказывается, там надо не просто хранить, а активно работать с ними, обновлять и пр. Вообще, топикстартер упорно хранит тайну - что надо делать? На вопрос- "можно ли посмотреть какой из процессов самый медленный" - ответ "да и так понятно что диск виноват" На вопрос- "а что там с запросами на чтение, посмотреть план" - ответ "да зачем план, и так понятно, база большая вот и медленно". Такой вот, диалог :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 17:01 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
MasterZiv , Вы пишите какие-то фантастические вещи. Загрузить все данные в память. Прверить их 60-ю потоками. После чего передать их какому-то "бульку", который скопирует их в таблицу. После чего загрузить данные из таблицы в память и начать их обработку - построение графиков, вычсление рангов.. итд. У меня такое впечатление, что после этого, обработанные данные надо поделить на части и снова передать "бульку", чтобы он записал их в разные таблицы. :) Вообще-то, загрузчик статистики должен параллельно скачивать из Inet-а 40 статистик и параллельно обновлять 40 баз. Если с каждой базой так "булькаться"... 15-20 статистик я пробовал - обновление локальных баз происходит за 9-10 часов. Суммарный объём баз 200-300 GB. Ну вот как-то так. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 17:32 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 Забавно : ЗабавноПросто, одну табличку. попробуйте на табличке типичные запросы. Причем, пока без удаления данных из нее и расчета агрегатов. Я уже писал выше. Нетути к SQL серверу никаких запросов! Он делает тупой insert и update. Вот когда он будет делать это не за 9 часов как сейчас, а за час, тогда появятся запросы. Забавноа все остальное (парсинг, и т.д.) обрабатывается на сервере или на клиенте? - ещё раз говорю - всё делает клиент. А сервер только insert и update. примерно 250 GB данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 17:49 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValНетути к SQL серверу никаких запросов!А нахрена ж вы тогда целую страницу тут распинались, что вот какой сервер бяка, простейший каунт (с ордербаем, хы) посчитать не может меньше чем за 2 секунды??! SerValвсё делает клиент.и даже данные проверяет тоже клиент? то есть сервер у вас по сути файлопомойка с SQL-интерфейсом? тогда тупо наращивайте дисковую подсистему, другого пути, наверное, нет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 18:35 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 19:19 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
2 S.G. : Я сначала не ответил на Ваш пост. Прошу принять мои извинения. S.G.Я вначале не имел ничего против. Вопрос звучал "как хранить" - ну если уже сделано так, пускай хранит в xml. Когда надо, вытащил пару графиков, показал. Но, оказывается, там надо не просто хранить, а активно работать с ними, обновлять и пр. Ну да. Кому ж нужны статические данные ? Всех интересует динамика. S.G.Вообще, топикстартер упорно хранит тайну - что надо делать? Надо побыстрее закатать полученные данные в базу. К SQL серверу никаких претензий не предьявляется. Чем быстрее он выполняет простые Insert и Update , тем лучше. Всё остальное готовит клиент. S.G.На вопрос- "а что там с запросами на чтение, посмотреть план" - ответ "да зачем план, и так понятно, база большая вот и медленно". Такой вот, диалог :) Ну вот типичный запрос на чтение: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Такой же "сложности" запросы к Users, Teams. S.G. , ну что здесь анализировать ??? Какой тут план запроса ??? :( 2 tanglir : А нахрена ж вы тогда целую страницу тут распинались, что вот какой сервер бяка, простейший каунт (с ордербаем, хы) посчитать не может меньше чем за 2 секунды??! Да, из-за того что база большая, выражение select COUNT(*) from Users я не применяю. Именно из-за медлючести. вместо него: Код: sql 1. где func dbo.nRows: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Про execution plan для select COUNT(*) from Users, я тоже ничего сказать не могу. :( tanglirто есть сервер у вас по сути файлопомойка с SQL-интерфейсом? Ну, он ещё таблички для сайта выдаёт. Тоже простыми селектами. tanglirтогда тупо наращивайте дисковую подсистему, другого пути, наверное, нет... Другой путь - уменьшать размеры данных, о чём я и спросил. Ну и я пока не знаю, можно ли ставить для SQL сервера SSD диски. Может быть четыре штуки по 256 GB в RAID0 не будут сильно изнашиваться ? (статистики нетути, поэтому - боюсь). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 19:43 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValНу и я пока не знаю, можно ли ставить для SQL сервера SSD диски. Может быть четыре штуки по 256 GB в RAID0 не будут сильно изнашиваться ? Вы сначала с обычными дисками разберитесь. Обычный одиночный SATAII имеет скорость записи раз в пять выше чем у вас там повыше показано. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 19:58 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovВы сначала с обычными дисками разберитесь. Обычный одиночный SATAII имеет скорость записи раз в пять выше чем у вас там повыше показано. Вы хотите сказать, что SQL сервер мог бы писать и побыстрее ? Вот чего HD-Tune показывает для диска Дата(db_date): ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 20:33 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValВот чего HD-Tune показывает для диска Дата(db_date): Это чтение. У тебя основная нагрузка - на запись. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 20:38 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValВы хотите сказать, что SQL сервер мог бы писать и побыстрее ? В силу использования лога транзакций, которым так любят размахивать в "Сравнении СУБД", он просто обязан писать на всю доступную скорость Sequential Write. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 20:41 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerVal 2 F# : F#1. Использовать не XML а бинарную серилизацию в блоб - XML избыточен Надо признаться, я не знаю, что такое блоб . Это varbinary(max) ? Ага "Бинарная серилизация в блоб".. как-то я плохо себе представляю что это такое. :( А при этой "бинарной серилизации в блоб" размер сохраняемых данных уменьшится ? Теоретически должен. ВОт посмотрите, зачем сам хранить выделенное жирным <chart> <title> Total Credit </title> <values> <x_value> 09.06.2012 </x_value> <y_value >0 </y_value> </values> ... </chart Это раз. Сделать бинарный формат, в котором будут только нужные биты ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 22:27 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
On 08/09/2012 06:32 PM, SerVal wrote: *MasterZiv*, Вы пишите какие-то фантастические вещи. Тебе =то лучше знать твою задачу, я только описываю возможности. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 22:55 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
On 08/09/2012 09:38 PM, Dimitry Sibiryakov wrote: > Это чтение. У тебя основная нагрузка - на запись. .... лога. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 23:51 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
> Надо признаться, я не знаю, что такое *блоб*. Это varbinary(max) ? > > > > Ага Нет, тип TEXT или LONG VARCHAR. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2012, 23:52 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerVal, 1. Из чего состоит 300 000 ГБ данных? На 300 000 пользователей это 1 МБ. Весь этот МБ НУЖЕН в БД? 2. MSSQL позволяет не логировать работу с таблицей? Или даже с БД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.08.2012, 10:07 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
АнатоЛойSerVal, 1. Из чего состоит 300 000 ГБ данных? На 300 000 пользователей это 1 МБ. Весь этот МБ НУЖЕН в БД? 2. MSSQL позволяет не логировать работу с таблицей? Или даже с БД? А вы уверены что автор указал именно объем данных в базе? Может, это размер файла с данными а может, размер лога, а может это их суммарный объем. А тормоза при добавлении данных - может у него первоначальный размер файлов бд маленький, а авторасширение установлено по 1 МБ, и клиент, который заливает данные, передает их по локальной сети? А модель восстановления какая? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.08.2012, 10:30 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerValНу вот типичный запрос на чтение: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Такой же "сложности" запросы к Users, Teams. S.G. , ну что здесь анализировать ??? Какой тут план запроса ??? :( В зависимости от того, есть ли индекс по id, план запроса, а также время выполнения, будут существенно разными. ps. Гм, может показаться, что я стою в позиции Капитана Очевидности, но в этом топике все совсем не очевидно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.08.2012, 10:45 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
насчёт неоднозначности - это точно... SerValЕсть ... (тут и далее порезаны приведённые факты... (с) АнатоЛой) Всё бы ничего, да когда число участников увеличивается размеры таблиц и сама база сильно растёт. :( (первое негативное отношение к факту. Все думают - ну растёт, ну и чё. У всех растёт :) (с) АнатоЛой). При числе участников в 300 тыс. размер базы увеличивается до 40-50 гигабайт. Соответвственно, показ участников в виде таблицы, со всякими join-нами тоже [b]тормозит - (второе негативное отношение к фактам (с) АнатоЛой)). Задержки в выводе страниц на экран становятся 3-4 секунды.[/b] :( (третье обозначенное отношение к фактам. Из чего участники обсуждения решают - проблема в скорости отображения данных!!! (с) АнатоЛой) В общем, изобретать велосипед не хочется. Посоветуйте что-нибудь. Или поделитесь, пожалуйста, опытом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.08.2012, 12:12 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
Из чего участники обсуждения решают - проблема в скорости отображения данных!!! Ребятки, у меня нет желания что-то скрывать. Просто, не хочется нагружать народ не относящимися к делу обстоятельствами. Да ещё сочтут за рекламу или ещё что... Ну раз уж вы оказались столь любезны, потараюсь развеять ваши сомнения и привести некоторые объяснения. Я делаю сводную статистику участников добровольных распределённых вычислений. Проектов распределённых вычислений около 60-ти. Каждый со своим сайтом, на который выкладывает статистику. Выкладывает в виде сжатых xml файлов. Эта статистика стандартизована и доступна для скачивания ВСЕМ. Для этого её и выкладывают. Даже расположение статистики стандартизовано: %SITE_URL%/stats Например: Статистика проекта Einstein@home Или : Статистика Российского проекта SAT@home Программа скачивает эти файлы, декомпрессирует, парсит участников, команды, компьютеры и запихивает их в таблицы Teams, Users, Hosts. Для показа на сайте: Сайт stats.boinc.ru Как я уже писал, входные данные - правоверные xml файлы. Например команда: Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. На основе даннных о команде программа формирует простейший INSERT into Team( id, type, name..) select @id, @type, @name.. То же самое для участников и их компьютеров. Как видите, ни большого ума, ни способностей тут не требуется. Ну, а поскольку народ интересует очки за последний день, неделю и месяц, программа добавляет графики. Ну, и вычисляет, места участников(ранги). Вот тут-то и оказалось, что графики занимают больше места, чем сами участники. ****************** Сейчас создал индексы для total_credit Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Посмотрю, теоретически должно помочь. Как проверю напишу. ***** 2 S.G. : id - PRIMARY KEY. Он, есессно, индексирован. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.08.2012, 14:35 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
Ха. Вот так всегда, как на любом специализированном сайте, сидят супер-пупер-крутые матёрые спецы и поучают глупеньких, обратившихся к ним за помощью. А как доходит до реальной, интересной и сложной задачи, так сразу в кусты и молчок. Стыдно, господа! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2013, 20:17 |
|
||
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#18+
SerVal, ну допустим.... 60 проектов, каждый из которых в стандартизированой форме (с неизменяемым количеством полей) выкладывает набор сущностей почему на каждую такую сущность не завести таблицу? Или если эти сущности совпадают, не завести общие таблицы для таких сущностей с дополнительным полем идентификатора проекта? В вашем же XML более 50% - паразитные (для БД) данные. то есть 45 Гб сразу жэе превратятся в 20. Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Опять таки, вопрос с предварительно рассчитанными агрегатами поднимался. Я ваш ответ не понял. Алгоритм подробный есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2013, 16:33 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1541270]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
50ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
111ms |
get tp. blocked users: |
1ms |
| others: | 214ms |
| total: | 418ms |

| 0 / 0 |
