|
Название: Организация БД Отправлено: demiurg от Май 07, 2011, 11:39 В процессе выполнения проекта столкнулся с проблемой оптимального пойска по БД.
Собственно есть около 1000 объектов которые заполняют ОДНУ И ТУЖЕ таблицу с 18 полями. При заполнении количество строк может быть от 5 до 10 млн и все идентификаторы объетов перемешаны. Я только начал работать с MySql и в непонятках как долго будет производиться поиск по 2-3 полям из этой таблицы , может стоит лучше организовать таблицу с названиями таблиц для каждого объекта? Название: Re: Организация БД Отправлено: majatu от Май 07, 2011, 13:23 насколько я знаю, скорость поиска будет зависеть от индексов полей таблиц бд, кластерный - некластерный и по какому полю будет идти поиск. В теории: если делать поиск по 2 миллионам записей из одной или по 100 тыщ, но в 18 и тоже из одной. То второй вариант будет быстрее конечно (если знаешь из какой таблицы выбирать).
Название: Re: Организация БД Отправлено: ioann от Май 08, 2011, 10:01 Если в твоей организации будет максимом 1000 человек, которые будут активно работать с БД, то оставь sql, а если количество пользователей превышает 1000 и будут очень огромные БД, то тут уже без oracle не обойтись.
Название: Re: Организация БД Отправлено: demiurg от Май 08, 2011, 11:44 Дело в том что максимум впринципе я пока не знаю ,но при удачных раскрутках - 1000-2000 думаю будет(тьфу тьфу тьфу) Смысл в том, что пользоваться БД они будут наоборот ОЧЕНЬ НЕАКТИВНО. 1 запрос раз в 1-5 дней ,а может и реже. А писаться будет асинхронно тоже с 1000-2000 объектов. Я пока что не столь долго пользовался БД чтобы сказать огромные это таблицы или нет. НО за год это не более 5-10 млн записей по 100-150 байт. Вот я и хочу решить для себя делать какбы трёхмерную, сотавную таблицу ( на ум приходит лишь создание кучи подтаблиц по 5000-10000 тыщ записей в каждой и ссылки на них в другой таблице) или одну большую с 5-10 млн записей.
Название: Re: Организация БД Отправлено: aliks-os от Май 09, 2011, 12:45 Трудно дать дельный совет не видя структуры БД. Но в любом случае нужно уделить внимание реляционным связям, индексам. На MySQL у меня построена систему управления предприятием, кол-во записей порядка 20 - 30 млн (есстественно не одна таблица), пользователей порядка 100, бд используется активно. Затыков в работе - нет.
Покажите структуру вашей БД и описание того что вам нужно. И тогда вы услышите нормальные внятные советы. А так все это тыкание пальцем в бублик. Название: Re: Организация БД Отправлено: demiurg от Май 09, 2011, 13:01 Код: +-------------+------------------------+------+-----+---------+-------+ таблица 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 таблиц для каждого объекта - "це е дюже муторно" в эксплуатации. Название: Re: Организация БД Отправлено: aliks-os от Май 09, 2011, 13:59 >а плодить 1000-2000 таблиц для каждого объекта - "це е дюже муторно" в эксплуатации.
Этого конечно делать не надо. Самое первое, что бросилось в глаза - отсутствие уникального ключевого поля с автоинкриментом! Думаю что такое поле необходимо создать. Я как понял, это у вас вроде какагото лога? Название: Re: Организация БД Отправлено: demiurg от Май 09, 2011, 14:08 Думаю что такое поле необходимо создать.
Сделать нужно конечно - это только тестовая таблица. Это накопитель данных для системы телеметрии. Каждый объект реальное устройство. Каждый объект просматривается какимто человеком через сайт. Впринципе выбрать 1000-5000 записей дело для человека недолгое (минута -две) - но БД грузится сильно. А если зайдёт 100-200 человек и будет давать запросы в одну таблицу ? Название: Re: Организация БД Отправлено: aliks-os от Май 09, 2011, 14:15 при выборке сделайте разделение для разных датчиков(объектов), типов записи, ограничьте по дате/времени. Соответственно для тех полей которые участвую в условии выборки, создайте индексы. Индексы очень сильно влияют на производительность поиска.
А что реально будут просматривать результаты телеметрии одновременно 100-200 человек? Может тогда есть смысл использовать выделенный мощный сервер? Название: Re: Организация БД Отправлено: aliks-os от Май 09, 2011, 14:19 Кроме того, просмотр для пользователя результата из 1000-1500 строк я думаю затруднительно. Постарайтесь продумать логику работы так, чтобы пользователь в результате получал не более 100-200 строк. Думаю что это облегчит ему анализ результатов выборки.
Название: Re: Организация БД Отправлено: demiurg от Май 09, 2011, 14:54 при выборке сделайте разделение для разных датчиков(объектов), типов записи, ограничьте по дате/времени. Соответственно для тех полей которые участвую в условии выборки, создайте индексы. Индексы очень сильно влияют на производительность поиска. Это вариант , всё равно нужно максимально ужать информацию выводимую пользователю. Ещё меня посетила идея создать две таблицы - одна как накопитель , другая активная ( например записи за последнюю неделю или месяц). Клиенты же в основном будут просматривать новые данные,а кому нужно раньше тогда обращаться к накопителю. Только для этого нужно или дублировать записи или как то реализовать механизм перенома одной таблицы в другую автоматом. В MySQL нет каких нибудь готовых решения этой задачи? А что реально будут просматривать результаты телеметрии одновременно 100-200 человек? Может тогда есть смысл использовать выделенный мощный сервер? Одновременно т.е.: зашёл человек на сайт после работы - залогинился, ему вывело например данные за последнюю неделю или даже день, переписал или отпечатал, вышел. Т.е. вероятность того что из 2000 клиентов 100-200 в одно и тоже время дадут запрос - очень низка, но существует. Вопрос в том как поведет себя БД. Зависнет? Название: Re: Организация БД Отправлено: aliks-os от Май 09, 2011, 15:12 Ещё меня посетила идея создать две таблицы - одна как накопитель , другая активная ( например записи за последнюю неделю или месяц). Этого делать не надо. Просто фильтруйте по дате, этого будет достаточно. На дату поставьте также индексОдновременно т.е.: зашёл человек на сайт после работы - залогинился, ему вывело например данные за последнюю неделю или даже день, переписал или отпечатал, вышел. Т.е. вероятность того что из 2000 клиентов 100-200 в одно и тоже время дадут запрос - очень низка, но существует. Вопрос в том как поведет себя БД. Зависнет? БД не зависнет, просто будет дольше выдавать строки. Так как у вас вероятность одновременного захода 100-200 человек мала, то я думаю что у вас обработка будет нормальная. Как я писал выше, постарайтесь чтобы пользователю за раз выдавалась не более 100 строк, желательно и еще меньше. В крайнем случае в пхп разбивайте их на страницы. Кстати, а почему вы вопрос задали здесь??? Данный сайт посвящен Qt а не PHP/MySQL Название: Re: Организация БД Отправлено: demiurg от Май 09, 2011, 15:36 Ладно буду шаманить. Спасибо за разъяснения.
Цитировать Кстати, а почему вы вопрос задали здесь Хотел изначально создать по таблице на каждый объект, а ссылки на талицы выдавать и хранить через написаный Qt сервак который бы работал как с объектами так и с клиентами. Но это ЖУТЬ какаято))) как теперь ясно стало ещё и трудно реализуемая. |