>>1189435 (OP)
Оп, хули ты просто выпернул тред и все? За тебя что ли вбрасывать? Btw, тред не взлетит - уже есть баз данных тред с дбашниками вместо населения. Ну ладно, вброшу.

> redis
> cassandra
Не нужно - есть Индеец Зажигай. Лучше во всем кроме апдейтов с кассандрой, там чуть хуже.

> mongodb
Говорят postgre лучше с джейсонами, когда их добавили и допилили.

Теперь отсоси мне, ты должен был это написать в оппосте, пидар.

>реляционные
>не реляционные

в чем разница? И какую технологию представляют не реляционные?

>>1189450
> Индеец Зажигай
Ето что?

> Говорят postgre лучше с джейсонами, когда их добавили и допилили.
Подтверждаю. Индексы и напердоленный язык запросов завезли, на триггеры можно повесить валидацию схемы и данных и жить как король. Ясен-красен, нереляционки не за JSON берут, если не долбоебы, но пострес пилят явно люди, умеющие в баланс между реляционным манямирком и нереляционным хуяк-хуяк-и-в-продакшен. Процедурки на Питоне, Перле и Lua — это вообще охуеть.

>>1189435 (OP)
Couchbase - круто или нет? Там всякие приколюхи типа репликации между клиентом Couchbase Mobile b/PouchDB и сервером на Couchbase.

Изучаю сейчас тарантул, суть такова: внутри однопоточный lua, работающий через корутины и к нему прицеплено хранилище, напоминающее монгу, то есть классические типизированные индексы, но данные можно хранить произвольной формы. Есть с персистенсом, есть inmemory, есть мастер-мастер репликация. Есть ещё транзакции, с которым надо будет поэкспериментировать ещё (+ как они заработают через репликацию), но с виду доверия особенного не внушают.

В целом мне нравится идея, мы как бы не изолируем полностью реализацию СУБД, а даём возможность её дописать под свои нужды, имея внутри достаточно мощные библиотеки, на 99% эту СУБД имплементирующие. Никаких эзотерических языков, как напридумывали для хранимок в SQL.

Что хуёво это очень древний луа (5.1), кооперативная многозадачность (можно неправильным кодом повесить весь инстанс), судя по документации нет VACUUM, то есть он постоянно беспрерывно просто срёт на диск, и вот ещё нужно выяснить насколько хуёвые там транзакции.

Насчёт монго: во-первых без транзакций очень плохо, почти все рано или поздно эти транзакции пытаются как-то наколхозить по мере развития проекта. Во-вторых полнотекстовый поиск умеет искать только по целым словам, там нет n-grams. В-третьих нет очень нужной функции CONVERT_TZ, и да, её нельзя сделать вычитая/добавляя N часов. В-четвёртых индекс устроен так, что при обновлении документа он временно оттуда вываливается, тем самым на какой-то момент пользователи не увидят какие-то документы в общем списке, хотя никто их оттуда не удалял. В-пятых, как по мне, очень мешает лимит 16Мб, особенно если какую-то сущность планируется эмбедить внутрь коллекции-родителя как список ObjectId. В-шестых, опять же, нет VACUUM.

ПГ справится со всеми этими недостатками. Слышал только что на ПГ сложно навернуть geodistance, сложно поставить PostGIS. А в монге оно из коробки работает норм. Ещё краем уха слышал что даже SQLite уже тоже себе добавляет json field.

>>1189450
Так ведь редиска - это кейвалуе структура в оперативке, а апач твайлайт спаркл - какая то поебота для хадупа.

Совсем ебанулся, дед?

>>1189526
Он про игнайт, а не спарк

>>1189502
>В целом мне нравится идея, мы как бы не изолируем полностью реализацию СУБД, а даём возможность её дописать под свои нужды
https://www.datomic.com/

А я напоминаю, что бд должна хранить данные, а не обрабатывать. Это для всяких
>В-третьих нет очень нужной функции CONVERT_TZ, и да, её нельзя сделать вычитая/добавляя N часов
Я хуй знает, в любом яп можно это сделать, прибавляя вычитая N часов, о чем ты?

>>1189765
Так давно же есть всякие PL/SQL с обычными переменными?

>>1189765
Хотя ладно, бд еще должна предоставлять доступ к данным, но на данный пример не вляет

>>1189765
Ты действительно, как ты выражаешься, «хуйзнает». Таймзоны это сложнее чем просто добавить N часов. Специально же написал об этом, видимо это трудно осознать. К примеру задача сделать group by по дням некоторых событий с учётом таймзоны пользователя.

>>1189765
Смотрите, ДИПЛОМИРОВАННЫЙ ДЖАВА СПЕЦИАЛИСТ собирается передавать данные с базы на сервер приложения, после чего отправлять их назад вместо того, чтобы их просто обработать на месте.

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

>>1189450
Я вкинул тред и у меня отрубили инет)

>>1189435 (OP)
Котаны, конкретно что в ОП пасту добавить? Копипаста для оппоста будет на pastebin. Мне интересна эта тема и надеюсь вам тоже.

>>1189435 (OP)
> MongoDB
> NodeJS
Встал вопрос как инкрементировать поле c MongoDB?
Хуки pre('save') и create не работают в схеме.
https://pastebin.com/1Md3Y6GJ
ЧЯДНТ?

>>1190057
Че ты бисер мечешь перед админом локалхоста?

Ананасы, застримьте на твиче какой нить хелловорлд на игните/ спарке / редисе.

>>1190057
>NoSQL треад
>datomic
>база сервера
>сервер базы
>сервер приложени
>кросс джоин
Да ты попупал, братишка

ЭЭэээ, вы чё, только монгодб здесь обсуждаете? Никто с ХБейсом, касадрой, нео4ж не работает?

>>1190480
Я с кассандрой работаю. Выше писал.
> ХБейсом
Лучше держаться от хадуп стека подальше, если есть возможность.

>>1190057
Ты конечно прав, но если тебе нужно джойнить записей на пару миллионов, то ты уже долбоеб.

>>1190585
Почему?

>>1190753
>Ты конечно прав, но если тебе нужно джойнить записей на пару миллионов,

Типичная ситуация в интырпрайз-бизнес логике - заказчик хочет именно такой вот хитровыебанный аналитический отчет.

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

>>1190815

В общем, смысл nosql баз данных - это замена оперативной памяти/кучи для всяких сетевых/применений, когда обычные SQL базы данных на роль оперативы годятся плохо.

>>1190798
Подумой.
>>1190815
Тред не для войтивайти и юаней. Поэтому и не понимаешь ничего.
>>1190818
Пиздеж.
>>1190826
> монга
> агрегирование
Ебать ты долбоеб, земля те пухом, братишка.

>>1189467
>Индеец Зажигай
>Ето что?
Видимо Apache Ignite

>>1190833
>Подумой.
Так почему?

хадуп это мап редьюс и ноды?

>>1190911
Мне откуда знать, я только кукарекать и кидаться говном умею зато хорошо

>>1190911
Если ты повидло или помидорка, то либо знаешь, либо поймешь, подумавши. А если юань и войтивайти, то даже объяснять бесполезно.

>>1191195
Анон постом выше таки оказался прав.

>>1191247
Не расплачься только, что никто не хочет тебя бесплатно обучать.

>>1191365
Диван диваныч, ты даже платно не сможешь, не льсти себе.

В чем срач то блядь?
Анон спросил чому от хадупа надо держаться подальше и почему стоит использовать кассандру?

Да епта, даже самая спелая помидорка, в розовой шубе на голое тело, не ответит на вопрос "почему так а не наоборот" если не шупала хадуп и кассандру.

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

Типо как загадка на собеседовании, на одном стуле хадуп, на втором игнит. На какой сам сядешь, какой мамаше поставишь

мимо

>>1191430
Именно так. Ответ предполагает наличие знания бигдаты. Есть кандидат написал в резюме, что он как Ленка БИГ ДАТА ДИСТРИБЬЮТЕД АРХИТЕКЧУРС СО СПЕШАЛ КЛАУД СПЕШИАЛИСТ и обдристывается, то значит, что он пиздит.

> хадуп зашквар, ноу вискас
На-на-на, хадуп стек не зашквар и у него много задач.

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

>>1191380
Каждые будни это делаю.

>>1191444
Бай зе вей, вопрос идет к помидорке с экспириенсом в обоих системах.
В каких случаях лучше телебонькать кассандру, а когда хуярить хадупом.

>>1191430
Если ты не можешь рационально объяснить выбор технологии, то у меня для тебя плохие новости.

>>1191444
>Каждые будни это делаю.
В техподдержке работаешь, лол?

мимо

Репощу тут. Когда-то был тред БД, но что-то не нашёл, спрошу тут. Есть около 50 миллионов записей по ~килобайту, нужно запилить удобный просмотр, сортировку и т.д. Вопрос по производительности. В идеале бы запилить в вебе чтоб не таскать везде БД, но я так понимаю с таким размером нужен оверпрайсный сервак если больше 3.5 человек будет пользоваться? На какие вообще скорости рассчитывать и сколько сожрет оперативки? В локальной БД же нормально будет шевелиться или на рядовой кофеварке 2ядра/4гига тоже будет больно?

>>1191521
Если ты можешь обьяснить выбор технологии когда не знаком ни с первым ни со вторым пунктом - у меня для тебя хорошие.

>>1191550
Ээ... ты о чем?

>>1191534
>50 миллионов записей по ~килобайту
>запилить в вебе
> В локальной БД
Ты планируешь всю эту мошну выгружать пользователю на страницу? Как? Почему? Зачем?

>>1191534
50 гигабайт голых данных это не бигдата нихуя. И 50 гигабайт чего?
Табличные данные? Ключ-значение? Логи с датой события и текстом? Что?

Для первых двух случаев (в твоем случае) берешь оракл, mssql, постгре, хуячишь схему под данные, добавляешь индексы если нада (если действительно надо, они не бесплатные) и загружаешь свои 50 гигабайт говна.
Для фронта к говну можно не писать обертку, а просто юзануть любую Data API платформу - например тот же Dreamfactory. Вот у тебя и фронт, и рест говнище, и секьюрити из коробки к твоему датасету. Только внимательно следи за запросами - они должны быть эффективными, никаких фуллсканов, никакой выгрузки половины БД за раз, только паджинирование, только хардкор.

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

Если же ни то, ни это, то depends.

>>1189786
о, бизнес-логика на БД подъехала

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

>>1189435 (OP)
Объясните, зачем нужны нереляционные бд?

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

Заказчик захотел после того, как данные уже есть.

>>1194763
>Объясните, зачем нужны нереляционные бд?

Чтобы обходить corner-case реляционных. В частности бессмысленные и беспощадные соединительные таблицы, потому что реляционные бд являются child->parent only.

>>1194763

Потому что постиндустриальная экономика "я сделяль! купи говно!".

Необходимость MRP II, строгих костюмов и прочих взрослых штук ушла, а вместе с ними и реляционные бд.

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

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

>>1194767
Открой для себя плоские таблицы.

Господа, поясните мне, есть у меня таблица в экселе, как то можно ее конвертировать в MS SQL, не руками ведь забивать?

>>1194825
Да

>>1194828
И как?

>>1194767
> бессмысленные и беспощадные соединительные таблицы
Ебать ты.

>>1194831
Скриптом создать SQL-запрос и затем его отправить в БД руками.

>>1194852
чо?

>>1194831
Csv

>>1194767
Ответ в общем правильный, а в частности бред какой-то написал.

>>1194857
Сто хуев тебе в рот через плечо.

>>1189435 (OP)
Анон, есть сайт, который сделан с помощью Django, база данных представляет собой mongoDB. Так вот, Анонче, как же можно сделать консольный запрос к базе к данных? Проблема усугубляется тем, что это не мой проект. Если слышал, про Open EDX, то поймешь о чем я. Документации хуй да нихуя. Так вот, кто разбирается в Django, помогите советом.

В общем пытаюсь импортировать из Excel'я в MS SQL. И чо за хуйня? На превьюхе первый пик. Только какого то хрена последние два столбца названы F7 и F8, а в таблице, которую я создавал O1 и O2. И уже на следующем шаге пик 2. Как чинить? Чего ему надо, сволочи этакой?

>>1194766
миграция, не?

>>1189435 (OP)
Расскажите вкратции что это хотя бы, интересно. Алсо, по моему имхо, с ними оче сложно работать.

>>1237570
Что значит сложно? Редис вообще k-v. У Клеппмана вообще целая глава есть про нереляционные бд. линк: https://www.ozon.ru/context/detail/id/144402960/

>>1189435 (OP)
Аноны, работал кто-нибудь с mongo дб?
У меня тут запрос, который делает много lookup'ов, сторонних коллекций в основную. К сожалению пока я их не могу убрать, так что ищу советов по по оптимизации. К счастью все эти лукапы не зависят друг от друга и могли бы выполняться параллельно. Я перепробовал несколько решений, пока единственное работающее было - через $facet, но оно оказалось в 2 раза медленнее обычной последовательности лукапов ( в причине чего кстати я не могу разобраться ). Может кто помочь?
inb4 да, я знаю что я пытаюсь восстоздать реляционную модель данных на нереляционной базе

>>1237570
Скажем, приспичило тебе в приложение прикрутить полнотекстовый и фасетный (как в каком-нибудь Амазоне) поиск и ты рррраааз такой и поднимаешь инстанс ИластикСерча или Солра, проводишь синхронизацию данных, прикручиваешь нужное API у себя на бекенде и бац (бац-бац-бацбац!) пользователи твоей системы могут искать всякую фигную и клацать на категории (подкатегории, под-подкатегории) разной шляпы и все это будет быстро-быстро. Только учти, что они основаны на Лусине, а она не транзакционная.
Или, скажем, приперло тебе прикрутить кэширование в свое приложение, т.к. каждый раз ходить в базу данных дорого и ваще не по-пацански и ты такой бац и прикручиваешь какой-нибудь Hazelcast или Redis и кэшируешь данные там, что делает твое приложение быстрее, а волосы мягкими и шелковистыми. Или вот взять пример, решил ты запилить сервис, который будет предлогать оптимальные туристические маршруты (на какой самолет сесть, где купить билет на автобус и как доехать). На всяких PostgreSQL это будет проблематично сделать, да и не для того их разрабатывали. И ты такой бац (бац-бац-бацбац) и уже не прошло и получаса как ты поднимаешь инстанс Neo4j, проектируешь свою модель данных в виде направленного графа и пишешь запросы к графовой базе данных, которая будет тебе за десятки миллисекунд прокладывать оптимальные туристические маршруты для твоих пользователей. Стоит ли говорить, что какая-нибудь реляционная база данных просто сдулась бы на первом запросе на ндцатом джоине выжрав всю память на сервере.

Добра! Пис!

И еще - если бы кто подсказал как полностью профилировать запросы в монго - было бы классно. Сейчас например я не могу в explain найти информацию о том, что происходит в lookup и т.д., только простейшие матчи.
анон >>1240701

>>1240701
Очевидные индексы очевидны.

>>1240744
Индексы добавил на foreignField, но explain почему-то не показывает информацию по ним вообще, так что я не могу понять - использует он их или нет. Судя по скорости - вроде да

>>1240747
нужно открыть документацию по этой вашей монги и прочесть раздел описывающий профилирование запросов.

>>1240754
Это я все сделал, очевидно, до того как зайти сюда. Нужной мне информации мне это не дало.

>>1240769
Да ничего ты не пытался. Версию монги не указал. А между прочим была целая куча багов по explain, который не мог нормально вывести данные по плану запроса. Да и сам запрос ты не предоставил. Вангую, что у тебя там кривой запрос и explain не туда воткнул ко всему прочему. Инфа соточка так сказать.

>>1240776
>Да ничего ты не пытался.
Понятно, можешь не утруждать себя
Уходи, зеленый

>>1240781
Он все правильно сказал. Ты просто ничего не смыслишь в разработке. Уже давно бы задал вопрос на SO.

>>1240828
лол, буйство семёна

>>1240852
Ну че, удалось получить план запроса? Или ты до сих пор ждешь ответа?

>>1241084
Я уже говорил что план аггрегации получить не проблема, но в нем нет никакой информации о не $match стадиях, просто копия из реквеста.
СО молчит.
Я конкретно ищу информацию о $lookup. В эксплейне - просто показывается копия стадии из реквеста, никаких данных об использовании индекса, длительности выполнения и т.д.