Так все данные у клиента. Клиентская программа только впихивает данные SQL серверу.
Выбирать пока нечего. А чтобы быстрее впихнуть, графики она компрессирует.

17 нитей впихивают 324562 участника в таблицу Users (по 20 тысяч каждая нить).
Самым простым INSERT-ом безо всяких условий.


Больше ничего. Какой тут может быть план ? Индексирован сейчас только 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).

2 tanglir :
tanglirЗачем тогда спрашивать?

Я спрашивал как зранить графики, чтобы они меньше места занимали.
Лучше - это когда на диск меньше пишется/читается.

Потому как простой запрос select count(*) from Hosts вызывает шмурыгание диска на 3-4 секунды.
Ну какие тут индексы нужны ? Или Execution Plan ? (я больше таким селестом не пользуюсь).

Я уж думал поставить базы на диск с компрессией данных, да чего-то опасюсь.
*****
tanglirНе пробовали через bulk insert (или как оно там в мсскл называется) эти же 5 Гб залить?
Не. Входные данные сырые и кривые. Проверять надо.

Сейчас переделываю: переношу графики - в другую таблицу. Формат прежний - compressed xml.
*****
Ребятки, спасибо за отклики и участие.

2 MasterZiv :
MasterZivПроверяй, а потом запихивай в bulk, кто ж мешает?

Ну что Вы в самом деле.. как это ""запихивай в bulk" ?
Мне ж надо сравнивать вчерашние и вновь полученные данные. Вчерашние-то куда ? В "бульк" уйдут ?
И что я сравнивать буду ???

И ещё: в полученных данных полно, например, участников без имени. Нам такие товарищи в статистике не нужны.
Запихиваем его в таблицу InvalidReceivedUser и продолжаем добавлять хороших в таблицу Users.
*****
Я смотрю сейчас на секционированные таблицы. Может можно новые данные загружать в новые секции.
А потом сравнить новое и старое, построить графики.. После чего убить старую секцию и нарезать ещё одну новую для нового дня.. итд.
Не знаю, правда, не слишком ли это сложно.

2 доброжелатель!!!!

Спасибо. Я примерно так уже переделываю.
Скорости это не прибавит(при нынешней структуре программы).
Но уже позволит не меняя таблицы Users, добавлять/удалять графики c меньшими затратами.
*****
А про нормальные формы уже почитал. Я советы не игнорирую, в какой бы форме они ни были высказаны.

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 год).

2 Dimitry Sibiryakov :
Dimitry SibiryakovДля хранения и выборки это может быть и копейки, но насколько я понял при добавлении
данных аффтар для каждого значения:
1) вытаскивает XML
2) парсит его
3) удаляет старейшее значение
4) добавляет новейшее
5) обратно компонует XML
6) сохраняет.

При таком стиле работы я удивляюсь, что он вообще способен дождаться окончания импорта.
Примерно так.
Однако ж я уже писал, что 60 нитей с готовыми INSERT-ами ждут, когда SQL сервер освободится для следущей записи на диск..
Нагрузка на процессор - никакая. Ну и сам SQL сервер тоже ждёт, пока что-то запишется на диск. :(

Тут никакие индексы не помогут. Средняя скорость записи SQL сервером на диск ~ 20-40 МБ в секунду. А иногда падает до 10. :(