Не индекс, три разных индекса. Это всё-таки первостепенной важности деталь.
Можно поиграться с засовыванием всех трёх значений в одно поле большого объёма с побитовым смещением и поиском по маске - удастся сэкономить на index merge. Но сомневаюсь в каких-то заметных дивидендах при явном ухудшении поддерживаемости.
Я, честно говоря, не в курсе, сколько стоит index merge - имеет ли вообще смысл искать пути для отказа от явного и простого варианта.
Вообще-то говоря, не обязательно пересобирать этот массив.
Разбить 4тб диск на два раздела по 2тб, добавить один раздел в имеющийся рейд, извлечь из него один 2тб диск, массив отребилдится как ни в чём не бывало; на этом извлечённом 2тб диске и втором разделе 4тб диска создать новый массив.
Веселее, если надо получить 4тб зеркало:
добавляем в массив этот 4тб диск, выкидываем один 2тб диск, ждём ребилда. Потом выкидываем второй 2тб диск, поверх имеющихся двух 2тб дисков делаем jbod и этот массив добавляем в зеркало к 4тб диску. Когда отребилдится - расширение массива на доступную ёмкость (команда у mdadm штатная, но не помню её).
> В лучшем случае получите spare drive для существующего Raid 1.
Почему? Зеркало можно собрать из любого числа дисков и все они могут быть активны одновременно.
В принципе, для 2тб массива в этом есть даже некоторых смысл - ребилдится такой объём довольно долго и есть шанс выпада и второго диска тоже.
Ну вот во время тормозов и смотреть.
Запишите пока типичные цифры загрузки, запишите ещё, сколько PPS (пакетов в секунду) и полоса пропускания используется на интерфейсах - чтобы сразу было с чем сравнивать.
> Но ведь в итоге каждый файл пустой, почему нельзя использовать один для всех?
Для удобства и автозагрузки. Каждому классу свой отдельный файл и по строго-определённому пути.
Пустой - потому что больше ничего и не надо. Достаточно наследуемого интерфейса.
FanatPHP:
> КАКОЙ СМЫСЛ делать quote и потом делать обрезание?
Мимикрировать под поведение экранирования, на которое ориентировано порядком существующего кода.
Чтобы мигрировать на нормальный PDO сразу и затем в спокойном режиме аккуратно заменять запросы на подготовленные.
Читайте исходный вопрос (про что вы очень любите на гране цензуры истерить)
> sql-запросы переписать не смогу, так как их очень много.
Какие технологии-то?
Если домен только зарегистрирован и не проявляет активности - может пройти не один месяц, прежде чем его заметят поисковики. По неосторожно засветившемуся рефереру в метрике/аналитике, случайной ссылке.
Современные технологии - они в хранении этих террабайт данных и быстром и качественном ранжировании по запросу. А сущность краулеров как была так и остались - ходить по всем встреченным ссылкам сети.
Опыт - именно что опыт. Сдохнут ведущие поисковики - на такой огромный спрос моментально вылезут другие. Как о них узнает, об этих новых? Всё так же.
И напомню о таком явлении современности как соцсети. Каков процент людей, которые кроме пары сайтов вообще никуда не ходят? Собственно, сама соцсеть поисковик и запустит.
Читайте историю. Это ведь совсем недавно было, всего-лишь прошлое тысячелетие.
Напрямую от разработчиков и авторов этих сайтов. И дальше по друзьям, знакомым и незнакомым.
Есть, наверное. 2015 год уже почти, как никак. Точно что-то для автоматического реконнекта есть.
Для openvpn гугл подсказывает keepalive, для ssh - мелкий башевый скрипт: stackoverflow.com/questions/6758897/how-to-set-up-...
Дополнительным плюсом такого решения - реплика пойдёт зашифрованная и не будет на мастере торчать открыто в мир.
