Многосерверность

Если мы поиск обсуждаем, то выплевывать приходится промили от того, что приходится лопатить для получения результата. Речь все-таки изначально шла о поиске?

Для каждого солюшена есть вполне себе линейная математика... зависимость между произвоидетельностью трансфера и канальной полосой... в большинстве солюшенов это прослеживается. Это отправная точка на самом деле при расчетах.

В первом посте есть какая цифра про 25k на документ, но можно к этому добавить еще необходимый transfer на документ... т.е. внутренний. Потом добавить всю мишуру, которая народу для обвеса ответа на поисковый запрос выплевывается в online... потом посмотреть на эти цифры и помедитировать.

PS. Мы же там про индексы какие-то?

Вот кстати, по Skype у нас тут дискуссия была, с одним из читающих. Хотелось бы добавить несколько слов в защиту модели с больших количеством поисковых серверов и общего стораджа.

Если взять, к примеру, этап балансировки запросов, а схемы с рапределением "буковок по серверам" тут были озвучены, то в нашем случае подобие такой балансировки вполне приемлимо.

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

Если поисковый индекс на общем storage оптимизирован с учетом кэширующего механизма операционной системы, то мы получаем ноды, которые при подачи на них однородного типа запросов, самооптимизируются как раз под данный тип запросов, а интенсивность чтения данных из общего storage заметно снижается.

Количество оперативной памяти и эффективность кэширования лежит на совести оптимизаторов индекса... разработчики индексов в математике будут по сильнее... им на самом деле виднее о чем речь идёт, просто надо обратить внимание на ОС и более детально рассмотреть какие-то механизмы.

Хочется еще добавить, что был опыт работы с подобными солюшенами, но самое первое на что надо обратить внимание это работоспособность ноды после очистки кэша. У меня не совсем поисковые задачи были, но принцип работы одинаковый. Балансировка может осуществля с обратной связью, а может и без. После очистки кэша, нагрузку на данный кусочек кластера надо снизить, т.к. возрастает нагрузка на чтение из общего хранилища и пока кэш не выползет на нужный уровень эффективности время ответа этой ноды значительно завышено от "паспортных" данных. В подобных системах, которые без должного запаса, после очистки кэша какой-то ноды без снижения интенсивности запросов... да она просто умирает, если защищающих механизмов нет.

IMHO оптимизация кластера на этапе балансировки играет значительную роль, т.к. в противном случае не будут использоваться низкоуровневые кэширующие механизмы, которые присутсвуют как в самой ОС, так и в корзинах... и даже в SCSI RAID контроллерах есть.

PS. Если кому-то пригодится, то всегда пожалуйста.

Если его грамотно приготовить, то всё будет просто летать со свистом... а дисковое место сейчас копейки стоит.

Надо стремиться к эфективности кэша в 96%... тогда и общий строрадж можно деражать на мене производительной корзине. После переведения ноды на новый индекс, прежде чем на неё пускать запросы, надо на ней прогнать все запросы из кэша... это будет быстрее, чем ждать пока его наполнит естественным путем.

На самом деле все зависит от того, как разложить данные в MySQL. Вон недавно была статейка от Google BigTable, где рассказывается в частности про то, что поисковый индекс (по-крайней мере его часть) лежит в индексном файле. Ну MySQL будет менее производительным, но при умелом сочетании хранения в MySQL и plaintext разница будет небольшая. Ну раза в два-три в худшем случае. Для небольших поисковых сервисов, дешевле, железок накупить, чем устранять эту разницу. Вот если бы разница была в в более чем 10-20 раз, как в случае с прямым раскладыванием индекса в реляционные таблицы, тогда имеет смысл и покумекать.

Да... истину глаголите... эти девелоперы, по 3.5k$ + бонус, они же сумашедшие порой бывают. Железом надо грамотно обставлять... все же дешевле, если на годовой бюджет пересчитать. Хотя всё от задачи зависит, т.к. админы по 3.5k$ + бонус, тоже... 😂 Как зарядят, что без CSS тут никак, а балансер на коленке это невозможно...

PS. Все упирается в деньги.

а что такие недешевые девелоперы. Это в России такие обитают? :-)

ну а сколько по Вашему должны стоить хорошие тим-лидеры со стажем?

Мы же не в Китае тут живём... люди приезжие... квартиру снять надо, машинку купить до работы катать, жена дом дети... посмотрите на цены в мск. После 17 часового дня надо отдохнуть хорошо... в стрип-бар по пути заехать, расслабится... на выходные на природу, пейнтболы, фитнесы, бассейны, аквапарки, лыжи в швейцарии... не все же красноглазые, специалисты же понимают сколько денег они своим работадателям зарабатывают. 😂

Ну я рад, что в России есть богатые и не очень жадные работодатели.

Ну дык посмотрите на уровень зарплат в том-же Яндаксе и т.д. и т.п. Все же упирается не только в деньги, а еще и в людей. Если уйдут, а команда еще сырая, то оно либо на одном месте топтаться будет, либо вообще развалится. Много хороших проектов по этой причине разваливается еще на стадии реализации.

PS. Если интересно, то можем mysql в multi master репликации обсудить. Буду признателен, если какие-то фидбеки будут... у меня все гладко работает, но отзывов не хватает... как заказчику ставишь, так начинается.

Вот статистика по сайтам софткпталогов

Страниц 3,809,484

Объем инфы незаархивированной = 100,85гб

В заархивированном виде в базе = около 25 гиг

Число уникальных слов = 3,876,319

Общее число слов =1,542,537,750