des1roer: Есть случаи, и их много, когда все данные помещаются в кеш, ну и зачем тогда держать две базы? И есть случаи, когда и сам кеш не нужен, ну и нафиг его.
PS. Прочитал по вашим ссылкам статьи из хабра, это как раз случаи неправильного выбора кувалды. Тем более они и сами пишут, что данные - реляционные, ну и зачем, собственно их понесло в монгу? С другой стороны у нас и монга и реляционка и где-то просто файлы конфигурации. Вот про файлы конфигурации у меня может быть рассказ "как я ушел с MySQL на файлы json"!
Из поиска мы получаем набор PK и/или FK, поля соответствия, релевантность и т.д. Если данных для отображения достаточно и не нужно лезть в базу, то их и используем. Если нужно что-то догрузить из базы - догружаем, сверяем, аккумулируем и т.д.
des1roer: Извиняюсь, наверное меня не совсем правильно поняли. Обычно "поиск" применяют так: есть база данных, реляционная или нет - без разницы, пусть будет реляционная. Рядом с ней стоит "поиск", как только что-то изменяется в связанных таблицах базы, асинхронно обновляются данные в "поиске". Нетипичные и полнотекстовые запросы делаются через "поиск", а вся остальная работа ведется в базе данных.
В этом случае получаем очень много преимуществ, фактически недоOLAP к нашим данным. Обновлять данные в "поиске" можно разными путями, как на каждый чих, так, например, и раз в полчаса по изменениям.
Еще раз, я не говорю "выкиньте свой SQL", я говорю "попробуйте проиндексировать свои данные не в SQL"! И заметьте, я не наставиваю, где эти данные должны храниться, в файлах, логах, блобах или таблицах...
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
PS. Прочитал по вашим ссылкам статьи из хабра, это как раз случаи неправильного выбора кувалды. Тем более они и сами пишут, что данные - реляционные, ну и зачем, собственно их понесло в монгу? С другой стороны у нас и монга и реляционка и где-то просто файлы конфигурации. Вот про файлы конфигурации у меня может быть рассказ "как я ушел с MySQL на файлы json"!