|
|
|
Как лучше хранить графики в базе данных ?
|
|||
|---|---|---|---|
|
#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?fid=32&msg=37911116&tid=1541270]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
66ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 241ms |
| total: | 403ms |

| 0 / 0 |
