База данных для хранения больших данных?

Какую базу данных выбрать ? Подойдет ли MySQL для этих задач?

При наличии должного опыта работы с ней, навыков правильного проектирования БД и полного понимания, зачем делать "именно так" и "почему не иначе?", думаю вполне подойдёт. А вообще, обычно базы оценивают не количеством записей в 1-ой (одной) таблице, а общим объёмом данных (в гига/пета- байтах) и некоторыми другими параметрами.

- поиск - есть ли запись в базе данных с указанным названием, если есть то обновляем данные там. Т.е. перед тем как добавить запись (а их напомню - вначале будет 5-40 млн и будут постоянно возрастать) будет проверять есть она в базе данных и добавлять/обновлять данные.

Для этого есть индексы, во всех известных мне базах. Предположительно - стандартный B-tree индекс, работает он во всех базах примерно одинаково.

На базу данных будут примерно такие нагрузки:

Нагрузки у Вас будут на железо а не на базу, если оно выдержит - то с точки зрения БД - логических проблем для хранения 40млн. записей - я не вижу.

Хочу узнать какими способами можно организовать структуру хранения большой информации ?

"Большой инфомрации" или больших объёмов данных? 40млн. записей - это совершенно не обязательно большой объём. Например индекс по числовому (INT) полю для 40млн. записей будет занимать всего несколько мегабайт. Для хранения именно "большой информации" - можете взять, например, PostgreSQL, там есть готовый механизм, TOAST, предназначенный специально для этого, или спроектировать базу MySQL таким образом, что бы нужные данные лежали отдельно от всякого "информационного мусора" ("хвостов"), это позволит сократить размер отдельной таблицы на диске и как следствие - повысить скорость работы с ней.

Каждый день или чуть реже нужно будет обновлять данные для 5-40 млн записей,

это обязательно сделать за один заход?

- поиск - есть ли запись в базе данных с указанным названием, если есть то обновляем данные там.

какого вида название? текст, хеш, инт? Длинна? В общем случае выборка по индексу происходит ОЧЕНЬ быстро, тут больше от железа зависит чем от базы.

- поиск по базе данных с указанными параметрами (например, чтобы такой-то параметр был больше указанного значения и подобные условия)

Индексы решают, если задача простые выборки из плоской таблицы - будет быстро, кроме вариантов поиска а ля `field` like %some text%.

Хочу узнать какими способами можно организовать структуру хранения большой информации ?

читайте "нормальные формы бд".

Какую базу данных выбрать ? Подойдет ли MySQL для этих задач?

Мускуль или постгес, тут уже надо смотреть на связку железо/софт, ибо у вас задача либо сильно нестандартная, либо что-то вы неверно проектируете, у вас же "суперсекретная задача", соответственно весьма пальцетыкательный ответ.

UPD:

Данные будут храниться в простом виде: строчка id,

надеюсь, это опечатка, в смысле - id типа integer?

Или может только хранить скажем категории и их номер в отдельной таблице. А в основной писать только номер категории.

читайте про нормализацию, нет, ну правда, это ВАЖНО.
Числовые данные ВСЕГДА работают быстрее смешанных(альфанумерик) при равной длине(в "символах"), надеюсь это очевидно. Соответственно выборка where categoryid = 55 будет работать быстрее чем where category = 'somecategoryname'. В остальном - не вижу особых проблем.

Каждый день или чуть реже нужно будет обновлять данные для 5-40 млн записей, и эта цифра будет постоянно расти, каждый месяц примерно на 5-10% записей в таблицу будет добавляться

Это скраппинг сервис (возможно, поисковик или какая-то аналитика соц.сети).

Я бы думал про то, как Вы будете производить получение данных до обновления для 5-40 млн записей в день на одном сервере: это ~500 запросов в секунду только для получения данных!

Вы же не хотите всё это засунуть на один сервер?!

mysql - будет достаточно. Главное позаботиться о разбиении на таблицы при приближении количества записей в одной таблице к лимитам.

Лимиты по кол-ву строк.

The MyISAM storage engine supports 2^32 rows per table, but you can build MySQL with the --with-big-tables option to make it support up to 2^64 rows per table.

использую монгу для хранения статистики по запросам в поисковиках
название -> хэшированный индекс.
в бд более 2 миллиардов записей - поиск и обновление занимает менее 1 миллисекунды.
более чем 10 раз быстрее ваших требований, при хранении в 50 раз больше данных.

Выше вам все верно расписали кроме одного. Нет вообще никаких причин использовать MySQL. Имхо берите PostgreSQL и наймите хорошего DBA