des1roer: Не, правильный поиск это хорошо. Например у меня есть датчик с полем HWANALOG="SIMATIC", есть датчик с полем HWPROTOCOL="SIMATIC", есть датчик PRODACTION="SIMATIC", так вот по слову SIMATIC я сразу найду все три датчика. В вашем же случае нужно будет отдельно, прямо или косвенно опрашивать эти поля.
Да и я знаю про провязочные таблицы, но уж поверьте, это совсем не легко, осуществлять по ним поиск.
И да, ничуть не умаляю SQL, более того, в своем ответе написал, что база данных как бы желательна (но не необходима). Sql/nosql, неважно. Но положив данные из базы (например) в правильный поисковик, уверяю, получите гораздо больше в плане поиска, а здесь как раз он и нужен.
Э???? А как сделать так, что два датчика разных производителей имеют разный набор характеристик? Как базу делать под это будем? А как потом искать по 10-20 характеристикам сразу и по трем четырем производителям? Тут автор топика правильный вопрос задает! Мы что под каждый датчик свою таблицу строить будем? SQL, оно, немного не того... для данной задачи.
Подытожу. Хотите чисто и без проблем. Собирайте свой комп (или берите HP) и ставьте debian/fedora/ubuntu server + KVM и управлялкой WebVirtmgr. Хотите энтерпрайзненько - exsi (будет абсолютно тоже самое + vendor lock от vmware). Хотите просто и со вкусом - оставайтесь на макосе и ставьте параллели или vmware. По ресурсам, производительности и функциональщине все будет в пределах 2-3% максимум!
Это я заявляю, как активный пользователь всего выше названного.
Ну а если хотите правильно, то сразу смотрите на железки с поддержкой SV-IOV, в частности адаптеров ethernet для самосборки и для покупного железа.
Я бы для дома и экскрементов остался бы на макмини и параллелях (у самого дома и iMac и Air и два макбука с параллелями). На работе куча серверов с KVM, на которых около 200 человек трудятся.
Да нет их чистых, нет и все тут! Я же написал, что все, абсолютно все гипервизоры работают под управлением операцоинки, будь то hyperv (windows) или exsi и xen (тот же линукс. И еще нужно посмотреть, сколько ресурсов отжирает линукс в exsi, против чистой макоси. Я так думаю, что поболее, загружая кучу служб для удаленного администрирования и всяких интерфейсрв типа iscsi инициаторов, nfs, vsfs и абсолютно ненужного вам энтерпрайзного барахла.
Вообще-то и параллели и KVM - именно гипервизоры, использующие соответствующие ресурсы процессора для виртуализации, как и xen и vmware и virtualbox. Так что это именно в вашем понимании "baremetal". И ведь никто не говорит, что и ксен и вмваре работают на линуксе, собственно как и kvm. И чем плохо ядро mach для этих целей? Это совсем не jail и даже не близко! Аппаратная виртуализация.
Мультикаст = локалка. По другому никак! С другой стороны, если у клиента уже есть старый кеш серверов, то он достаточно быстро будет старотовать. фактически так делает битторрент, и не только...
И да, ну нет, нету в глобальном интернете мультикаста! Что-то нам обещает переход на IPv6 с его anycast, но мне кажется, то провайдеры будут его закрывать... (очень кажется)
А обязательно знать каждого? может быть достаточно знать 3-10 рабочих? Да сам механизм достаточно простой, координации никакой не нужно, просто рассылаем рандомно 5-6 серверам свой весь свой список. Через некоторое время все сервера будут знать всех.
Виталий Пухов: Увы, IP-протокол, который маршрутизируется в глобальной сети, устроен так, что нужна точка входа или несколько точек.
Все P2P сети устроены аналогично. Есть изначальный пул точек входа, с которых мы получаем "последние зерегистрированные IP-адреса", далее проходим по ним и подключаемся к живому серверу.
Технически, клиенты в P2P являются и серверами, тогда можно у любого клиента спросить список других клиентов.
Но при запуске всё равно нужно знать хоть пару-тройку живых серверов.
Виталий Пухов: Сделайте пул координаторов, сервер, при включении регистрируется на одном из координаторов, координаторы обмениваются адресами серверов. Все координаторы имеют одно DNS имя. Сам сервер DNS будет клиентам раздавать адреса координаторов по round-robin - https://ru.wikipedia.org/wiki/Round_robin_DNS
Еще раз хочу подчеркнуть. Если у вас данные уже лежат в таблицах, то не нужно их дублировать! Соответственно, не вижу никакой необходимости в теблице отчетов совсем! Отчет - это один или несколько запросов по уже существующими данным + их обработка.
Другой случай, когда обработка у нас занимает продолжительное время и мы знаем, что переложив данные в более удобный вид мы сэкономим себе кучу времени для выборки этих данных в дальнейшем. Другими словами, один раз долго посчитав, мы сохраняем результаты и все последующие разы просто их просматриваем.
Я бы большее внимание обратил на сами данные и прогнозы. Прогноз же строится на какой-то период (по моему), а измерения проводятся в конкретный момент. Может быть имеет смысл связать сразу прогноз и измерения при заливке результатов измерений в базу? Другими словами, одна строка в таблице прогноза может соответствовать нескольким строкам с измерениями?
Ну и конечно у MySQL есть специальные возможности по переливке запросов из таблицы в таблицу. См. "insert into select" - www.mysql.ru/docs/man/INSERT_SELECT.html . Есть более правильный синкаксис "select into", но он в MySQL не реализован, но есть в PostgeSQL.
