Дело не в петабайтах, а в количестве перезаписи одного блока. Даже если сброс на диск сделать асинхронным и вхреначить памяти побольше, боюсь при огромных количествах перезаписях не долго они протянут. Пока заявленные цифры перезаписи блока малы, так то конечно я за SSD их скорость отличная, но пока приходится использовать SAS.
Тут надо смотреть для чего больше база используется. Если больше для чтения то да. У меня к примеру все проекты работают постоянно на запись и обновление данных в базе. Я не решаюсь использовать SSD. В сутки проходит около 100 000 000 апдейтов, пот посудите сами, если у SSD заявено что он выжевит только 10 000-100 000 перезаписей одного блока, то насколько мне бы хватило этих дисков? В моей ситуации даже на slave нельзя SSD ставить, так как репликация неприрывная. Поэтому чтобы вы не говорили SAS в RAID помоему пока самое адекватное решение для БД.
SSD на базах не катит, у SSD 10000-100000 перезаписей блока, при большом обьеме изменений, диски будут лететь только в путь. Боюсь, что лучше SAS RAID пока ничего нет…
Но основной проблемой нечеткого поиска всегда было то что индекс нельзя построить по нему, точнее можно но он будет бухнуть на глазах и его эффективность будет равна не то что бы нулю, а даже будет еще хуже, вот если кто то еще опубликует статью как быть с производительностью при огромных словарях я буду очень рад.
Заходя на указанный сайт likeloverr.com в посте вижу надпись «Cookiweb a pris la dйcision de Fermer ce site dйfinitivement et n'est en aucun cas responsable, la sociйtй ayant йtй seulement йditrice du site, merci de votre comprйhension...»
http://letters.wmtransfer.com/
Но основной проблемой нечеткого поиска всегда было то что индекс нельзя построить по нему, точнее можно но он будет бухнуть на глазах и его эффективность будет равна не то что бы нулю, а даже будет еще хуже, вот если кто то еще опубликует статью как быть с производительностью при огромных словарях я буду очень рад.
Спасибо за статью.
Взломал кто то со злости что ли его?