Это несомненно, но в сабже было про объяснение на пальцах и нубскую реализацию

ну я и привёл пример, как ещё более не надо делать нейросети

C/С++, фортран и прочие языки без оверхеда. Если уж высокоуровневые брать, то только вызывать интерфейсы у быстрых библиотек

о, мне нравится Ваша подборка. особенно си и фортран )

Вызывать чьи-то интерфейсы - это не написание своей нейросети

и кстати он завис, после ответа на последний вопрос))

это вместо "мы вам перезвоним")

это вместо "мы вам перезвоним")

тонко)

вообще, про связной я что-то погорячился, первоначально в виду вот это имел http://xor.ai/faq

в подробности того, насколько там все интеллектуально, не вникал, но вроде как что-то такое заявлялось. пруфов не будет)

Вызывать чьи-то интерфейсы - это не написание своей нейросети

дёргать MKL, BLAS и LAPACK ещё вполне допустимо

вообще, про связной я что-то погорячился, первоначально в виду вот это имел http://xor.ai/faq

ну вот, у нас связной-анкетка - у людей это. по крайней мере выглядит точно солиднее, а как работает проверим

ну вот, у нас связной-анкетка - у людей это. по крайней мере выглядит точно солиднее, а как работает проверим

жаль, бюджеты не раскрывают. а было бы интересно сравнить.

Привет!)

жаль, бюджеты не раскрывают. а было бы интересно сравнить.

Бюджет это вообще абстрактная штука

На одну и ту же задачу могут выделить совершенно разные суммы, считаемые разными способами, и каждый будет прав

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

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

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

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

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

дёргать MKL, BLAS и LAPACK ещё вполне допустимо

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

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

Есть задача - сохранять очень много текстовой информации (в перспективе - терабайты). По ряду причин, все должно храниться в рамках одного сервера. ОС Linux. Какую реляционную СУБД выбрать для обеспечения как приемлемой скорости записи (данные поступают со скоростью порядка пары мегабайт в секунду), так и хорошей скорости чтения (планируются сложные запросы либо с джойнами, либо серии подряд идущих запросов без джойнов)? Запросы относительно редки, но время ожидания тоже не должно быть большим. Сохранность данных на первом месте. Сейчас рассматриваю MariaDB+TokuDB, Firebird, Cassandra (сильно не уверен из-за ее нереляционности). Склоняюсь к первому, но, может, у кого-нибудь были похожие задачи?

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

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

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

Больше записи. Выборки рандомные, чаще по ключевым полям, но относительно редкая часть запросов будет по LIKE %бла%блабла%. Про шардинг пока не думал, предполагается все хранить на одном сервере, соответственно, на одной ноде СУБД. Сохранность данных очень важна, но там, скорее всего, будет RAID с полным зеркалированием. Начинать со своего велосипеда тоже не очень-то хочется )

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

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

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

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

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

Тоже верно.

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

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

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

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

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

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

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

Поддерживаю

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

Тоже хотел про него упомянуть, но все зависит от задачи. Если она больше напоминает архивирование, да к тому же на одной машине, то преимущества тарантула будут не существенные. Он крут, когда много машин, все синхронизируется, разнородные данные и на них накручнено много бизнес-логики.

А делать со строками что планируется? Читать по ключу? Или агрегировать?

Ещё стоит подумать о том, на сколько данные "реляционны"? Может стоит глянуть на монгу и её механизм map-reduce

Много белых пятен в задаче, для нас)

А делать со строками что планируется? Читать по ключу? Или агрегировать?

Читать по ключу или по LIKEам

Ещё стоит подумать о том, на сколько данные "реляционны"? Может стоит глянуть на монгу и её механизм map-reduce

Монга + Toku? Там, скорее, сетевая структура. Просто в реляционных БД сети вполне неплохо хранятся. С монгой надо будет мучаться.

Я вот быстро и по ключу в Аэроспайке хорошо читал

Монга + Toku? Там, скорее, сетевая структура. Просто в реляционных БД сети вполне неплохо хранятся. С монгой надо будет мучаться.

Ясно

Много белых пятен в задаче, для нас)

Да я понимаю )))

Ладно, пойду спать. Всем спокойной ночи

Сетевая случаем не граф ?

Тарантул - это такой redis + application server, оба плохо работают с большими ключами, ну и хранят только столько, сколько помещается в память. Cassandra не масштабируется при ключах в мегабайты длиной. Вообще, хранить в базе данных что-то большее килобайт - путь к io stalls. Хранить в одном месте байты и мегабайты - похоже на ошибку. Искать по этому с помощью like% - вы точно понмаете, что делаете?

Да я понимаю )))

Удачи

Начать надо с mysql+innodb и увидеть, где проблемы

Учитывая, что озвучено - постгре или току. Выбор зависит от админа. И та и другая в руках отличного админа в пять раз быстрее, чем в руках хорошего. Поэтому что админ лучше знает.

что за строчки в мегабайты длиной в одном ключе? их точно нельзя порезать на части?

Тарантул - это такой redis + application server, оба плохо работают с большими ключами, ну и хранят только столько, сколько помещается в память. Cassandra не масштабируется при ключах в мегабайты длиной. Вообще, хранить в базе данных что-то большее килобайт - путь к io stalls. Хранить в одном месте байты и мегабайты - похоже на ошибку. Искать по этому с помощью like% - вы точно понмаете, что делаете?

Поддерживаю про io. Возможно, архитектуру можно улучшить

что за строчки в мегабайты длиной в одном ключе? их точно нельзя порезать на части?

Может геном бактерии

геномы пакуются через rANS например, и зчем в одной базе бактерия с миллионом букв и тут же бактерия с десятью буквами? такие вообще бывают?

геномы пакуются через rANS например, и зчем в одной базе бактерия с миллионом букв и тут же бактерия с десятью буквами? такие вообще бывают?

Не знаю, я предположил

вот что для упаковки геномов специально придумали: https://github.com/jkbonfield/rans_static

но это еще без lz, т.е. не подойдет для упаковки строчек в условной базе данных

вот что для упаковки геномов специально придумали: https://github.com/jkbonfield/rans_static

Спасибо, ознакомлюсь на досуге

Тарантул - это такой redis + application server, оба плохо работают с большими ключами, ну и хранят только столько, сколько помещается в память. Cassandra не масштабируется при ключах в мегабайты длиной. Вообще, хранить в базе данных что-то большее килобайт - путь к io stalls. Хранить в одном месте байты и мегабайты - похоже на ошибку. Искать по этому с помощью like% - вы точно понмаете, что делаете?

Я в процессе обдумывания самой идеи, так что я пока еще не совсем понимаю, что делаю, т.к. ничего не делаю. Ваш комментарий весьма дельный, кстати. Спасибо.

что за строчки в мегабайты длиной в одном ключе? их точно нельзя порезать на части?

Ну это, скорее всего, будут не ключевые поля, но по ним нужен полнотекстовый поиск. Надо будет посмотреть на эластик.

Всем, кто отвечал, спасибо!

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

в принципе, sphinx как-то живет и на нескольких нодах, но я не пробовал, а для эластика такая конфигурация родная

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

а сфинкс научился поддерживать что нибудь кроме mysql? Лично я голосую за эластик. Главное - его настроить, ибо настройка из коробки ужасна, а вот его гибкость в настройке - почти безгранична

сфинкс умеет mysql, postresql, mssql и odbc, есть xml загрузчик (не знаю, кто им пользуется), и относительно недавно появились tsv/csv загрузчики

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

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

я знаю, что такое сфинкс

я с ним работал во времена mysql 5.0 и тогда он мог только с mysql работать. Это похоронило надежду на перевод одного крупного проекта на постгрес

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

нет, раньше точно не умел. Если теперь умеет - это отличная новость

да, сейчас без проблем загружает, там даже odbc есть, так что из любого sql сможет, хоть из db2 или оракла какого

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

Можно хранить данные в качестве атрибутов (строки/булы/числа)

привет!!!

привет!!!

Привет :)

Господа вашу бих дату в большом автосервисе можно использовать? Есть готовый бизнес план/идея как юзать чтобы показать хозяину? И вам хорошо будет и мне?

напиши в личку, обсудим

интересно, насколько же большим должен быть автосервис, чтобы бигдата принесла там профит...