Но было бы интересно собрать такую статистику и посмотреть зависимости

Ребята, всем привет)

И тебе привет=)

Ни одного минуса в той статье не было. Только "у нас уже Theano, зачем нам еще либа. Это ж не минус :)

Дергать blas и lapack для нейронов - это как сайт на си писать. Можно, но как-то не принято.

Куда лучше записывать логи профилирования?

Есть задача - сохранять очень много текстовой информации (в перспективе - терабайты). По ряду причин, все должно храниться в рамках одного сервера. ОС Linux.

Какую реляционную СУБД выбрать для обеспечения как приемлемой скорости записи (данные поступают со скоростью порядка пары мегабайт в секунду), так и хорошей скорости чтения (планируются сложные запросы либо с джойнами, либо серии подряд идущих запросов без джойнов)?

Запросы относительно редки, но время ожидания тоже не должно быть большим. Сохранность данных на первом месте.

Сейчас рассматриваю MariaDB+TokuDB, Firebird, Cassandra (сильно не уверен из-за ее нереляционности). Склоняюсь к первому, но, может, у кого-нибудь были похожие задачи?

Каков тип текстовой информации ? Каков размер записи ?

В зависимости от того, какой характер нагрузки, решения могут быть очень разными. Чего больше: чтения или записи? Выборки последовательные или рандомные? По каким критериям идет выборка? Как планируется шардить данные, какие требования к резервированию? и т.д. т т.п… В перспективе: под узкие специфичные задачи на больших масштабах, как правило, выгоднее свое кастомное хранилище, написанное на си (возможно, как плагин к какой-то системе). Только не надо с этого начинать, поставьте любую СУБД (ту же maria) и дойдите с ней хотя бы до N гигабайт .)

Больше записи.

Выборки рандомные, чаще по ключевым полям, но относительно редкая часть запросов будет по LIKE %бла%блабла%.

Про шардинг пока не думал, предполагается все хранить на одном сервере, соответственно, на одной ноде СУБД.

Сохранность данных очень важна, но там, скорее всего, будет RAID с полным зеркалированием.

Начинать со своего велосипеда тоже не очень-то хочется )

Строки UTF-8 переменной длины. От пары символов до нескольких мегабайт.

Мне кажется, что стоит обратить внимание не только на выбор СУБД, но и раздел файловой системы, где будет хранилище.

А что насчет PostgreSQL? Есть ли выгода про сравнению с TokuDB?

Тоже верно.

Тут нужно пробовать. ПГ хороша. Но её нужно уметь настраивать.

Мне кажется, что стоит попробовать maria+toku. Если нет, то уже думать.

Я еще думал насчёт Tarantool, но тогда придется полностью пересматривать структуру базы, приводя ее к key-value схеме. И далеко не факт, что это даст какие-либо преимущества.

Наверное, так и сделаю.

А бизнес задача какая ? так мб проще будет посоветовать базу

Поддерживаю