Организация БД

[demiurg]

В процессе выполнения проекта столкнулся с проблемой оптимального пойска по БД.

Собственно есть около 1000 объектов которые заполняют  ОДНУ И ТУЖЕ таблицу  с 18  полями. При заполнении количество строк может быть от 5 до 10 млн и все идентификаторы объетов перемешаны. Я только начал работать с MySql  и в непонятках как долго будет производиться поиск по 2-3 полям из этой таблицы , может стоит лучше организовать таблицу с названиями таблиц для каждого объекта?

[majatu]

насколько я знаю, скорость поиска будет зависеть от индексов полей таблиц бд, кластерный - некластерный и по какому полю будет идти поиск. В теории: если делать поиск по 2 миллионам записей из одной или по 100 тыщ, но в 18 и тоже из одной. То второй вариант будет быстрее конечно (если знаешь из какой таблицы выбирать).

[ioann]

Если в твоей организации будет максимом 1000 человек, которые будут активно работать с БД, то оставь sql, а если количество пользователей превышает 1000 и будут очень огромные БД, то тут уже без oracle не обойтись.

[demiurg]

Дело в том что максимум  впринципе я пока не знаю  ,но при удачных раскрутках - 1000-2000  думаю будет(тьфу тьфу тьфу) Смысл в том, что пользоваться БД они будут наоборот ОЧЕНЬ НЕАКТИВНО. 1 запрос раз в 1-5 дней ,а может и реже. А писаться будет асинхронно тоже с 1000-2000 объектов. Я пока что не столь долго пользовался БД чтобы сказать огромные это таблицы  или нет. НО за год это не более 5-10 млн записей по 100-150 байт. Вот я и хочу решить для себя делать какбы трёхмерную, сотавную таблицу ( на ум приходит лишь создание кучи подтаблиц по 5000-10000 тыщ записей в каждой  и ссылки на них в другой таблице) или одну большую с 5-10 млн записей.

[aliks-os]

Трудно дать дельный совет не видя структуры БД. Но в любом случае нужно уделить внимание реляционным связям, индексам. На MySQL у меня построена систему управления предприятием, кол-во записей порядка 20 - 30 млн (есстественно не одна таблица), пользователей порядка 100, бд используется активно. Затыков в работе - нет.

Покажите структуру вашей БД и описание того что вам нужно. И тогда вы услышите нормальные внятные советы. А так все это тыкание пальцем в бублик.

[demiurg]

Код:

+-------------+------------------------+------+-----+---------+-------+
| Field       | Type                   | Null | Key | Default | Extra |
+-------------+------------------------+------+-----+---------+-------+
| day         | tinyint(5) unsigned    | YES  |     | NULL    |       |
| month       | tinyint(5) unsigned    | YES  |     | NULL    |       |
| year        | tinyint(5) unsigned    | YES  |     | NULL    |       |
| hour        | tinyint(5) unsigned    | YES  |     | NULL    |       |
| minute      | tinyint(5) unsigned    | YES  |     | NULL    |       |
| Snum        | mediumint(25) unsigned | YES  |     | NULL    |       |
| IMEI        | varchar(25)            | YES  |     | NULL    |       |
| type        | varchar(5)             | YES  |     | NULL    |       |
| Vnum        | varchar(25)            | YES  |     | NULL    |       |
| work_hour   | mediumint(10) unsigned | YES  |     | NULL    |       |
| energy      | varchar(20)            | YES  |     | NULL    |       |
| vol1        | varchar(20)            | YES  |     | NULL    |       |
| vol2        | varchar(20)            | YES  |     | NULL    |       |
| consumption | varchar(10)            | YES  |     | NULL    |       |
| temp1       | varchar(10)            | YES  |     | NULL    |       |
| temp2       | varchar(10)            | YES  |     | NULL    |       |
| error       | varchar(6)             | YES  |     | NULL    |       |
| battary     | smallint(5)            | YES  |     | NULL    |       |
| sim_number  | varchar(15)            | YES  |     | NULL    |       |
| money       | smallint(8)            | YES  |     | NULL    |       |
+-------------+------------------------+------+-----+---------+-------+

таблица 1 - данные - идентификатор SNUM(не ключ - реальный серийный номер)

Собственно это основная таблица, ещё одна таблица содержит Snum  и IMEI  - параметры соответствия для  входа в систему.

Далее данные забираются через PHP по запросу (SELECT * WHERE SNUM  = чемуто ) или (SELECT * WHERE SNUM  = чемуто AND day>дня AND month>месяца ) ну и на страницу сайта.  (TIMESTAMP чот не пошёл через Qt - пришлось разложить на составляющие:))
Т.е. струтура элементарная. никаких сложных связей. Просто накопитель данных.

В этой таблице могут быть разные объекты с разными идентификаторами SNUM. НО со временем число записей в ней станет очень большим( к примеру 5000 записей с одним SNUM, а таких SNUM  1000-2000 штук). Я тут полазил вобщем и ненашёл ничего про составные многомерные таблицы в MySQL , а плодить 1000-2000 таблиц для каждого объекта - "це е дюже муторно" в эксплуатации.  

[aliks-os]

>а плодить 1000-2000 таблиц для каждого объекта - "це е дюже муторно" в эксплуатации.
Этого конечно делать не надо.

Самое первое, что бросилось в глаза - отсутствие уникального ключевого поля с автоинкриментом! Думаю что такое поле необходимо создать.

Я как понял, это у вас вроде какагото лога?

[demiurg]

Думаю что такое поле необходимо создать.
Сделать нужно конечно - это только тестовая таблица.

Это накопитель данных для системы телеметрии. Каждый объект реальное устройство. Каждый объект просматривается какимто человеком через сайт. Впринципе выбрать 1000-5000 записей дело для человека недолгое (минута -две) - но БД грузится сильно. А если зайдёт 100-200 человек и будет давать запросы в одну таблицу ?  

[aliks-os]

при выборке сделайте разделение для разных датчиков(объектов), типов записи, ограничьте по дате/времени. Соответственно для тех полей которые участвую в условии выборки, создайте индексы. Индексы очень сильно влияют на производительность поиска.

А что реально будут просматривать результаты телеметрии одновременно 100-200 человек? Может тогда есть смысл использовать выделенный мощный сервер?

[aliks-os]

Кроме того, просмотр для пользователя результата из 1000-1500 строк я думаю затруднительно. Постарайтесь продумать логику работы так, чтобы пользователь в результате получал не более 100-200 строк. Думаю что это облегчит ему анализ результатов выборки.

[demiurg]

при выборке сделайте разделение для разных датчиков(объектов), типов записи, ограничьте по дате/времени. Соответственно для тех полей которые участвую в условии выборки, создайте индексы. Индексы очень сильно влияют на производительность поиска.

Это вариант , всё равно нужно максимально ужать информацию выводимую пользователю. Ещё меня посетила идея создать две таблицы - одна как накопитель , другая активная ( например записи за последнюю неделю или месяц). Клиенты же в основном будут просматривать новые данные,а кому нужно раньше тогда обращаться к накопителю. Только для этого нужно или дублировать записи или как то реализовать механизм перенома одной таблицы в другую автоматом. В MySQL нет каких нибудь готовых решения этой задачи?

А что реально будут просматривать результаты телеметрии одновременно 100-200 человек? Может тогда есть смысл использовать выделенный мощный сервер?

Одновременно т.е.: зашёл человек на сайт после работы - залогинился, ему вывело например данные за последнюю неделю  или даже день, переписал или отпечатал, вышел. Т.е. вероятность того что из 2000 клиентов 100-200 в одно и тоже время дадут запрос - очень низка, но существует. Вопрос в том как поведет себя БД. Зависнет?

[aliks-os]

Ещё меня посетила идея создать две таблицы - одна как накопитель , другая активная ( например записи за последнюю неделю или месяц).

Этого делать не надо. Просто фильтруйте по дате, этого будет достаточно. На дату поставьте также индекс

Одновременно т.е.: зашёл человек на сайт после работы - залогинился, ему вывело например данные за последнюю неделю  или даже день, переписал или отпечатал, вышел. Т.е. вероятность того что из 2000 клиентов 100-200 в одно и тоже время дадут запрос - очень низка, но существует. Вопрос в том как поведет себя БД. Зависнет?

БД не зависнет, просто будет дольше выдавать строки. Так как у вас вероятность одновременного захода 100-200 человек мала, то я думаю что у вас обработка будет нормальная. Как я писал выше, постарайтесь чтобы пользователю за раз выдавалась не более 100 строк, желательно и еще меньше. В крайнем случае в пхп разбивайте их на страницы.

Кстати, а почему вы вопрос задали здесь Данный сайт посвящен Qt а не PHP/MySQL

[demiurg]

Ладно буду шаманить. Спасибо за разъяснения.

Кстати, а почему вы вопрос задали здесь

Хотел изначально создать по таблице на каждый объект, а ссылки на талицы выдавать и хранить через написаный Qt сервак который бы работал как с объектами так и с клиентами. Но это ЖУТЬ какаято))) как теперь ясно стало ещё и трудно реализуемая.