Сергей

Тут правильно говорят про LOAD DATA INFILE 'xxx' INTO TABLE 'xxx', только одна оговорка -- файл должен быть локальным по отношению к mysql-серверу.
У меня была задача сгенерировать 80 млн записей 4кб текста (вырезанного из 100 Кб шаблонного текста).

Я в своё время сделал так (т.к. php и mysql работал на одной машине):
1. Сделал RAM-диск, и примонтировал его к ФС.
2. На этот рам диск я писал нужные мне данные в CSV объемом где то 1 гб
3. Загружал в mysql с помощью LOAD DATA ...

Как показывали расчеты, если бы я это делал с помощью INSERT INTO то это продолжалось бы в районе 11 часов. Используя LOAD DATA я уложился в 40 мин. Причем сам по себе экспорт данных 1 Гб в mysql занимал порядка 10 сек, время генерации 1Гб файлика на php составляло порядка 3 минут, отсюда выводы --- берите LOAD DATA ... и готовьте с помощью него, вещь годная.

Я прям не знаю что Вам ответить.
Начните с себя. Неважно на чем вы будете писать и как, главное пишите.
Как начнете писать, так через некоторое время поймете как лучше начинать и что делать, и потом уже начинайте "правильно" как сами захотите. Здесь вам никто не подскажет ответы на ваши вопросы.

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

Почитайте ТК РФ.

Статья 241. Пределы материальной ответственности работника

[Трудовой кодекс РФ] [Глава 39] [Статья 241]
За причиненный ущерб работник несет материальную ответственность в пределах своего среднего месячного заработка, если иное не предусмотрено настоящим Кодексом или иными федеральными законами.

Здравствуйте. А мне ваша задача интересна. Напишите, пожалуйста на loguntsov at gmail dot com

У вас картинка структуры БД поломалась.

$('ul li ul li') - ?

Вам видимо нужен инструмент на подобии трансляции: C++ -> LLVM -> Python. Может и есть такое. Транслируют же люди ASM в Javascript. Наверно и тут также можно.

А можно не использовать C++ с его дедлоками, и работой с памятью. Достаточно поменять инструмент решения проблемы. Например взять Erlang, где проблемы параллельного программирования сведены к минимуму + можно подключать C\C++\что-то еще вставки для быстродействия.

1. Использовать много разных DNS для ресолвинга имен.
2. Использовать многопоточный парсер, который будет создавать 100000 потоков для парсинга + 1000 для определения доменного имени + увязать это все одно целое. Как вариант использовать для этого дела Erlang ;)

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

попробуйте squashfs. Минус - это то что нужно будет периодически пересоздавать её для обновления данных, т.к. эта fs - Read-Only. Плюс - компрессия.

Попробуйте хранить в БД данные. Например у MySQL есть тип таблиц Archive - осуществляется поиск по 1 primary key, в свою очередь данные также сжимаются, и также таблица read-only, записи могут добавляться, но не изменяться.

Вы можете организовать несколько томов\таблиц, и обновлять их по мере необходимости, перегоняя данные из одной таблицы\тома в другой.

Ваша задача в общем случае сводится к аппроксимации целевой функции многих переменных.
Например: Стоимость авто расчитывается из таких чисел как: объем двигателя, пробег, год выпуска и т.п.
исходными данными для такого дела могут быть объявления о покупке\продажи авто с соотвествующих сайтов. Целевая функция -- стоимость этого авто. Т.о. используя мат обеспечение вы можете аппроксимировать такую функцию многих переменных, и применять её к уже другим исходным данным и получать эквивалентную стоимость вашего авто.

А вот экспертная система это набор правил для вывода одних данных из других. Как вы её будете обучать, мне непонятно.

MODx удобно использовать как своего рода снежный ком, на который можно лепить что угодно.
По части отсутствия версионного контроля - обходится небольшим куском кода, который подгружает отдельные php-файлы в нужных местах.

MODx хорошо использовать для админки, а писать сам сайт на обычном php.
Конечно у MODx куча минусов, но серьезные продукты делать можно. Проверено на практике.

Лучше подумайте над тем какие преимущества дадут вам SQL против NoSQL. Сейчас модно говорить об NoSQL, но это всего лишь слова. А что вы будете делать когда схема БД будет меняться? Когда возникнут потребности в выборках которые вы не предусмотрели изначально? NoSQL хорош там, где нужна помощь SQL-решениям. Как самостоятельное primary решение я думаю его даже не стоит рассматривать.

Все исходя из ваших потребностей. Например написание параллельные программы на С++ в корне отличается чем для Erlang\Go, в которых это делается намного легче (конечно с определенными ограничениями).

Мне кажется вам нужно использовать старый CD-ROM, причем по возможности несколько.
Делаете полный образ комакт-диска (ISO).
Далее скорее всего в сети есть ПО для объединения/вытаскивания информации. Например имеем 3 байта в одном и том же месте на 3х разных образах, один байт не совпадает с 2мя остальными - т.о. достаточно большая вероятность того, что на данном месте должен быть байт который присутвует у 2х образов одновременно.