Ян Ко: да, бывал, причем печальный. Если raid5, то лобязательно с хотспаре. Лучше, конечно raid10, но не все могут себе его позволить. Софтверный лучше восстанавливается. Мы сейчас вообще перешли на hba-адаптеры, все raid делаем в софте. Более того, просто взяли и развернули ceph и ненарадуемся больше года. Есть и скилл восстановления ceph(rbd) из месива, но здесь сами себе были злобные буратины.
Здесь же советую конфигурацию для сервера, который скорее всего будет 1U, а в него более четырех дисков 3,25 не влазит :-(
Что касается горячей замены, то это не привилегия адаптера или контроллера, а привилегия бекплейна, у нас например работает дискокопирка на матьбордовом sata с блоком салазок с горячей заменой, заливаем по 100 дисков раз в месяц, все четко.
И что же предложить для 4-х дисков?! Raid10 расточительно, raid6, на запись оптимизировать нужно, остается raid5 с горячей заменой. Остальное - регулярные бекапы на внешнее хранилище!!! Если воткнуть аппаратный рейд, то на таком количестве дисков разница производительности все равно не будет заметна, проверено не раз.
Ну, да, давайте воткнем 2U с 12-ю дисками, с аппаратным рейдом и увеличим стоимость сервера и размещения в два раза. Хорошее предложение.
Упс, ip-ресиверы конечно... И посмотрите мой ответ, на счет простой програмки на gstreamer. Gstreamer вещает мультикастом сразу на все точки одновременно. Через gstreamer аудиопоток и принимается на концах и выдается в линейный аудио выход. Другими словами, есть один комп-передатчик и куча компов-приемников, синхронизация автоматическая. Можно даже не писать программу! Поставьте везде mpd, вместо gstreamer.. www.musicpd.org
Ух, оптику варят, пригласите сварщика и он все сделает, или сразу закажите с разъемами на концах. Медиаконвертеры и оптика сделает вам линию ethernet в 600 метров. Далее или сами через компы мультикастом или через ip-расиверы. Я же не знаю ваш бюджет, можно дорого и красиво, а можно, если умеете программировать, на расберри пи. Вариантов масса..
Нет, усилители за меня подбирают. Я в этом деле как свинья в апельсинах. Догадываюсь, что подбираются они в соответсвии с мощностью усиления с расчетом на длину кабеля (затухания типа).
По моему, так они все ничего, если не трещат и наводок паразитных нет. У нас ребята их как-то осцилографом проверяют на искажения. Но, блин, я по программам.
Ну что, досмотрел про aiohttp, очень неплохо! Понравилось сравнение с торнадо, и что они не будут делать мегамонстра. Вообще очень, на первый взгляд, вкусно. буду пробовать. Комментарии порадовали.
На счет того, нужен или нет торнадо, он простой как две копейки, за неделю освоите полностью. А на aiohttp я сейчас и сам гляну. Про торнадо уже сказал, быстрота и простота рулит у него.
Tark: О!!! Как раз для этого (хранение и обработка в играх) очень часто его пользуют. Ну и конечно мне нравится - 5 строк кода и у вас готовый сервер с батарейкой, + 10 строк кода и уже готовое приложение!
Это кто же сказал, что торнадо и "длительная обработка запроса" как-то связаны?! Просто их, запросы к базе, делайте асинхронно. Хотя на чистом торнадо может быть так и есть, я всё больше за cyclone (клон торнадо) + twisted.
des1roer: Есть случаи, и их много, когда все данные помещаются в кеш, ну и зачем тогда держать две базы? И есть случаи, когда и сам кеш не нужен, ну и нафиг его.
PS. Прочитал по вашим ссылкам статьи из хабра, это как раз случаи неправильного выбора кувалды. Тем более они и сами пишут, что данные - реляционные, ну и зачем, собственно их понесло в монгу? С другой стороны у нас и монга и реляционка и где-то просто файлы конфигурации. Вот про файлы конфигурации у меня может быть рассказ "как я ушел с MySQL на файлы json"!
Из поиска мы получаем набор PK и/или FK, поля соответствия, релевантность и т.д. Если данных для отображения достаточно и не нужно лезть в базу, то их и используем. Если нужно что-то догрузить из базы - догружаем, сверяем, аккумулируем и т.д.
des1roer: Извиняюсь, наверное меня не совсем правильно поняли. Обычно "поиск" применяют так: есть база данных, реляционная или нет - без разницы, пусть будет реляционная. Рядом с ней стоит "поиск", как только что-то изменяется в связанных таблицах базы, асинхронно обновляются данные в "поиске". Нетипичные и полнотекстовые запросы делаются через "поиск", а вся остальная работа ведется в базе данных.
В этом случае получаем очень много преимуществ, фактически недоOLAP к нашим данным. Обновлять данные в "поиске" можно разными путями, как на каждый чих, так, например, и раз в полчаса по изменениям.
Еще раз, я не говорю "выкиньте свой SQL", я говорю "попробуйте проиндексировать свои данные не в SQL"! И заметьте, я не наставиваю, где эти данные должны храниться, в файлах, логах, блобах или таблицах...
Здесь же советую конфигурацию для сервера, который скорее всего будет 1U, а в него более четырех дисков 3,25 не влазит :-(
Что касается горячей замены, то это не привилегия адаптера или контроллера, а привилегия бекплейна, у нас например работает дискокопирка на матьбордовом sata с блоком салазок с горячей заменой, заливаем по 100 дисков раз в месяц, все четко.
И что же предложить для 4-х дисков?! Raid10 расточительно, raid6, на запись оптимизировать нужно, остается raid5 с горячей заменой. Остальное - регулярные бекапы на внешнее хранилище!!! Если воткнуть аппаратный рейд, то на таком количестве дисков разница производительности все равно не будет заметна, проверено не раз.
Ну, да, давайте воткнем 2U с 12-ю дисками, с аппаратным рейдом и увеличим стоимость сервера и размещения в два раза. Хорошее предложение.