Нереляционных баз данных тред
Оп, хули ты просто выпернул тред и все? За тебя что ли вбрасывать? Btw, тред не взлетит - уже есть баз данных тред с дбашниками вместо населения. Ну ладно, вброшу.
> redis
> cassandra
Не нужно - есть Индеец Зажигай. Лучше во всем кроме апдейтов с кассандрой, там чуть хуже.
> mongodb
Говорят postgre лучше с джейсонами, когда их добавили и допилили.
Теперь отсоси мне, ты должен был это написать в оппосте, пидар.
>реляционные
>не реляционные
в чем разница? И какую технологию представляют не реляционные?
>не реляционные
в чем разница? И какую технологию представляют не реляционные?
> Индеец Зажигай
Ето что?
> Говорят postgre лучше с джейсонами, когда их добавили и допилили.
Подтверждаю. Индексы и напердоленный язык запросов завезли, на триггеры можно повесить валидацию схемы и данных и жить как король. Ясен-красен, нереляционки не за JSON берут, если не долбоебы, но пострес пилят явно люди, умеющие в баланс между реляционным манямирком и нереляционным хуяк-хуяк-и-в-продакшен. Процедурки на Питоне, Перле и Lua — это вообще охуеть.
Couchbase - круто или нет? Там всякие приколюхи типа репликации между клиентом Couchbase Mobile b/PouchDB и сервером на Couchbase.
Изучаю сейчас тарантул, суть такова: внутри однопоточный lua, работающий через корутины и к нему прицеплено хранилище, напоминающее монгу, то есть классические типизированные индексы, но данные можно хранить произвольной формы. Есть с персистенсом, есть inmemory, есть мастер-мастер репликация. Есть ещё транзакции, с которым надо будет поэкспериментировать ещё (+ как они заработают через репликацию), но с виду доверия особенного не внушают.
В целом мне нравится идея, мы как бы не изолируем полностью реализацию СУБД, а даём возможность её дописать под свои нужды, имея внутри достаточно мощные библиотеки, на 99% эту СУБД имплементирующие. Никаких эзотерических языков, как напридумывали для хранимок в SQL.
Что хуёво это очень древний луа (5.1), кооперативная многозадачность (можно неправильным кодом повесить весь инстанс), судя по документации нет VACUUM, то есть он постоянно беспрерывно просто срёт на диск, и вот ещё нужно выяснить насколько хуёвые там транзакции.
В целом мне нравится идея, мы как бы не изолируем полностью реализацию СУБД, а даём возможность её дописать под свои нужды, имея внутри достаточно мощные библиотеки, на 99% эту СУБД имплементирующие. Никаких эзотерических языков, как напридумывали для хранимок в SQL.
Что хуёво это очень древний луа (5.1), кооперативная многозадачность (можно неправильным кодом повесить весь инстанс), судя по документации нет VACUUM, то есть он постоянно беспрерывно просто срёт на диск, и вот ещё нужно выяснить насколько хуёвые там транзакции.
Насчёт монго: во-первых без транзакций очень плохо, почти все рано или поздно эти транзакции пытаются как-то наколхозить по мере развития проекта. Во-вторых полнотекстовый поиск умеет искать только по целым словам, там нет n-grams. В-третьих нет очень нужной функции CONVERT_TZ, и да, её нельзя сделать вычитая/добавляя N часов. В-четвёртых индекс устроен так, что при обновлении документа он временно оттуда вываливается, тем самым на какой-то момент пользователи не увидят какие-то документы в общем списке, хотя никто их оттуда не удалял. В-пятых, как по мне, очень мешает лимит 16Мб, особенно если какую-то сущность планируется эмбедить внутрь коллекции-родителя как список ObjectId. В-шестых, опять же, нет VACUUM.
ПГ справится со всеми этими недостатками. Слышал только что на ПГ сложно навернуть geodistance, сложно поставить PostGIS. А в монге оно из коробки работает норм. Ещё краем уха слышал что даже SQLite уже тоже себе добавляет json field.
ПГ справится со всеми этими недостатками. Слышал только что на ПГ сложно навернуть geodistance, сложно поставить PostGIS. А в монге оно из коробки работает норм. Ещё краем уха слышал что даже SQLite уже тоже себе добавляет json field.
Так ведь редиска - это кейвалуе структура в оперативке, а апач твайлайт спаркл - какая то поебота для хадупа.
Совсем ебанулся, дед?
Он про игнайт, а не спарк
>В целом мне нравится идея, мы как бы не изолируем полностью реализацию СУБД, а даём возможность её дописать под свои нужды
https://www.datomic.com/
А я напоминаю, что бд должна хранить данные, а не обрабатывать. Это для всяких
>В-третьих нет очень нужной функции CONVERT_TZ, и да, её нельзя сделать вычитая/добавляя N часов
Я хуй знает, в любом яп можно это сделать, прибавляя вычитая N часов, о чем ты?
>В-третьих нет очень нужной функции CONVERT_TZ, и да, её нельзя сделать вычитая/добавляя N часов
Я хуй знает, в любом яп можно это сделать, прибавляя вычитая N часов, о чем ты?
Так давно же есть всякие PL/SQL с обычными переменными?
Хотя ладно, бд еще должна предоставлять доступ к данным, но на данный пример не вляет
Ты действительно, как ты выражаешься, «хуйзнает». Таймзоны это сложнее чем просто добавить N часов. Специально же написал об этом, видимо это трудно осознать. К примеру задача сделать group by по дням некоторых событий с учётом таймзоны пользователя.
Смотрите, ДИПЛОМИРОВАННЫЙ ДЖАВА СПЕЦИАЛИСТ собирается передавать данные с базы на сервер приложения, после чего отправлять их назад вместо того, чтобы их просто обработать на месте.
Сколько недель будешь расссчитывать хотя бы небольшой кросс джоин таблиц на пару миллионов значений, которые следует сгруппировать?
Я вкинул тред и у меня отрубили инет)
Котаны, конкретно что в ОП пасту добавить? Копипаста для оппоста будет на pastebin. Мне интересна эта тема и надеюсь вам тоже.
> MongoDB
> NodeJS
Встал вопрос как инкрементировать поле c MongoDB?
Хуки pre('save') и create не работают в схеме.
https://pastebin.com/1Md3Y6GJ
ЧЯДНТ?
Че ты бисер мечешь перед админом локалхоста?
Ананасы, застримьте на твиче какой нить хелловорлд на игните/ спарке / редисе.
SUP
mongdb, версия 3.2.11.
Пытаюсь сделать юзеров и выдать им права доступа к базам. Смотрел и на офф. сайте и гуглил. Создаю командой createUser и в параметре roles указываю список из одного элемента (root для root или dbAdminAnyDatabase для администратора, например). В обоих случаях в параметр roles автоматически прописывается параметр db (смотрю по записям в документе). В итоге и root, и администратор работают только для одной базы, а в других у них прав нет.
Это нормально для mongodb или я не то делаю? Возможно сделать юзера с правами администратора для всех баз?
mongdb, версия 3.2.11.
Пытаюсь сделать юзеров и выдать им права доступа к базам. Смотрел и на офф. сайте и гуглил. Создаю командой createUser и в параметре roles указываю список из одного элемента (root для root или dbAdminAnyDatabase для администратора, например). В обоих случаях в параметр roles автоматически прописывается параметр db (смотрю по записям в документе). В итоге и root, и администратор работают только для одной базы, а в других у них прав нет.
Это нормально для mongodb или я не то делаю? Возможно сделать юзера с правами администратора для всех баз?
>NoSQL треад
>datomic
>база сервера
>сервер базы
>сервер приложени
>кросс джоин
Да ты попупал, братишка
ЭЭэээ, вы чё, только монгодб здесь обсуждаете? Никто с ХБейсом, касадрой, нео4ж не работает?
Я с кассандрой работаю. Выше писал.
> ХБейсом
Лучше держаться от хадуп стека подальше, если есть возможность.
Ты конечно прав, но если тебе нужно джойнить записей на пару миллионов, то ты уже долбоеб.
Почему?
>Ты конечно прав, но если тебе нужно джойнить записей на пару миллионов,
Типичная ситуация в интырпрайз-бизнес логике - заказчик хочет именно такой вот хитровыебанный аналитический отчет.
Ну вы хоть описывайте свою говнину так чтобы посторонние поняли о чём оно и где его применять. А то какие-то там апдейты лучше/хуже, это ж ни о чём не говорит.
В общем, смысл nosql баз данных - это замена оперативной памяти/кучи для всяких сетевых/применений, когда обычные SQL базы данных на роль оперативы годятся плохо.
Подумой.
Тред не для войтивайти и юаней. Поэтому и не понимаешь ничего.
Пиздеж.
> монга
> агрегирование
Ебать ты долбоеб, земля те пухом, братишка.
>Индеец Зажигай
>Ето что?
Видимо Apache Ignite
>Подумой.
Так почему?
хадуп это мап редьюс и ноды?
Мне откуда знать, я только кукарекать и кидаться говном умею зато хорошо
Если ты повидло или помидорка, то либо знаешь, либо поймешь, подумавши. А если юань и войтивайти, то даже объяснять бесполезно.
Анон постом выше таки оказался прав.
Не расплачься только, что никто не хочет тебя бесплатно обучать.
Диван диваныч, ты даже платно не сможешь, не льсти себе.
В чем срач то блядь?
Анон спросил чому от хадупа надо держаться подальше и почему стоит использовать кассандру?
Да епта, даже самая спелая помидорка, в розовой шубе на голое тело, не ответит на вопрос "почему так а не наоборот" если не шупала хадуп и кассандру.
Самый блядь адекватный ответ от подумавшего повидла - хадуп зашквар, ноу вискас.
Типо как загадка на собеседовании, на одном стуле хадуп, на втором игнит. На какой сам сядешь, какой мамаше поставишь
мимо
Анон спросил чому от хадупа надо держаться подальше и почему стоит использовать кассандру?
Да епта, даже самая спелая помидорка, в розовой шубе на голое тело, не ответит на вопрос "почему так а не наоборот" если не шупала хадуп и кассандру.
Самый блядь адекватный ответ от подумавшего повидла - хадуп зашквар, ноу вискас.
Типо как загадка на собеседовании, на одном стуле хадуп, на втором игнит. На какой сам сядешь, какой мамаше поставишь
мимо
Именно так. Ответ предполагает наличие знания бигдаты. Есть кандидат написал в резюме, что он как Ленка БИГ ДАТА ДИСТРИБЬЮТЕД АРХИТЕКЧУРС СО СПЕШАЛ КЛАУД СПЕШИАЛИСТ и обдристывается, то значит, что он пиздит.
> хадуп зашквар, ноу вискас
На-на-на, хадуп стек не зашквар и у него много задач.
> Типо как загадка на собеседовании, на одном стуле хадуп, на втором игнит. На какой сам сядешь, какой мамаше поставишь
Валидный вопрос если человек работал с обоими технологиями. Если сможет пояснить, то он как минимум имеет представление об обоих. Если нет, то просто умное слово в резюме написал.
Каждые будни это делаю.
Бай зе вей, вопрос идет к помидорке с экспириенсом в обоих системах.
В каких случаях лучше телебонькать кассандру, а когда хуярить хадупом.
Если ты не можешь рационально объяснить выбор технологии, то у меня для тебя плохие новости.
>Каждые будни это делаю.
В техподдержке работаешь, лол?
мимо
Репощу тут. Когда-то был тред БД, но что-то не нашёл, спрошу тут. Есть около 50 миллионов записей по ~килобайту, нужно запилить удобный просмотр, сортировку и т.д. Вопрос по производительности. В идеале бы запилить в вебе чтоб не таскать везде БД, но я так понимаю с таким размером нужен оверпрайсный сервак если больше 3.5 человек будет пользоваться? На какие вообще скорости рассчитывать и сколько сожрет оперативки? В локальной БД же нормально будет шевелиться или на рядовой кофеварке 2ядра/4гига тоже будет больно?
Если ты можешь обьяснить выбор технологии когда не знаком ни с первым ни со вторым пунктом - у меня для тебя хорошие.
Ээ... ты о чем?
>50 миллионов записей по ~килобайту
>запилить в вебе
> В локальной БД
Ты планируешь всю эту мошну выгружать пользователю на страницу? Как? Почему? Зачем?
50 гигабайт голых данных это не бигдата нихуя. И 50 гигабайт чего?
Табличные данные? Ключ-значение? Логи с датой события и текстом? Что?
Для первых двух случаев (в твоем случае) берешь оракл, mssql, постгре, хуячишь схему под данные, добавляешь индексы если нада (если действительно надо, они не бесплатные) и загружаешь свои 50 гигабайт говна.
Для фронта к говну можно не писать обертку, а просто юзануть любую Data API платформу - например тот же Dreamfactory. Вот у тебя и фронт, и рест говнище, и секьюрити из коробки к твоему датасету. Только внимательно следи за запросами - они должны быть эффективными, никаких фуллсканов, никакой выгрузки половины БД за раз, только паджинирование, только хардкор.
В третьем случае поднимаешь ELK, грузишь датасет и обмазываешься полнотекстовым поиском и визуализацией данных.
Если же ни то, ни это, то depends.
о, бизнес-логика на БД подъехала
ну так сагрегируй данные заранее и положи в отдельную банку для отчетов, нахуя одну банку насиловать и перегружать ответственностью?
Объясните, зачем нужны нереляционные бд?
>ну так сагрегируй данные заранее и положи в отдельную банку для отчетов, нахуя одну банку насиловать и перегружать ответственностью?
Заказчик захотел после того, как данные уже есть.
>Объясните, зачем нужны нереляционные бд?
Чтобы обходить corner-case реляционных. В частности бессмысленные и беспощадные соединительные таблицы, потому что реляционные бд являются child->parent only.
Потому что постиндустриальная экономика "я сделяль! купи говно!".
Необходимость MRP II, строгих костюмов и прочих взрослых штук ушла, а вместе с ними и реляционные бд.
Теперь главная задача - чтобы хипстосайт выдержал хабраэффект хомячков и загнать его какому-нибудь лоху.
Вот для осуществления главной задачи - предпродажного выдерживания наплыва хомяков и существуют нереляционные бд.
Открой для себя плоские таблицы.
Господа, поясните мне, есть у меня таблица в экселе, как то можно ее конвертировать в MS SQL, не руками ведь забивать?
Да
И как?
> бессмысленные и беспощадные соединительные таблицы
Ебать ты.
Скриптом создать SQL-запрос и затем его отправить в БД руками.
чо?
Csv
Ответ в общем правильный, а в частности бред какой-то написал.
Сто хуев тебе в рот через плечо.
Анон, есть сайт, который сделан с помощью Django, база данных представляет собой mongoDB. Так вот, Анонче, как же можно сделать консольный запрос к базе к данных? Проблема усугубляется тем, что это не мой проект. Если слышал, про Open EDX, то поймешь о чем я. Документации хуй да нихуя. Так вот, кто разбирается в Django, помогите советом.
В общем пытаюсь импортировать из Excel'я в MS SQL. И чо за хуйня? На превьюхе первый пик. Только какого то хрена последние два столбца названы F7 и F8, а в таблице, которую я создавал O1 и O2. И уже на следующем шаге пик 2. Как чинить? Чего ему надо, сволочи этакой?
миграция, не?
Расскажите вкратции что это хотя бы, интересно. Алсо, по моему имхо, с ними оче сложно работать.
Что значит сложно? Редис вообще k-v. У Клеппмана вообще целая глава есть про нереляционные бд. линк: https://www.ozon.ru/context/detail/id/144402960/
Аноны, работал кто-нибудь с mongo дб?
У меня тут запрос, который делает много lookup'ов, сторонних коллекций в основную. К сожалению пока я их не могу убрать, так что ищу советов по по оптимизации. К счастью все эти лукапы не зависят друг от друга и могли бы выполняться параллельно. Я перепробовал несколько решений, пока единственное работающее было - через $facet, но оно оказалось в 2 раза медленнее обычной последовательности лукапов ( в причине чего кстати я не могу разобраться ). Может кто помочь?
inb4 да, я знаю что я пытаюсь восстоздать реляционную модель данных на нереляционной базе
Скажем, приспичило тебе в приложение прикрутить полнотекстовый и фасетный (как в каком-нибудь Амазоне) поиск и ты рррраааз такой и поднимаешь инстанс ИластикСерча или Солра, проводишь синхронизацию данных, прикручиваешь нужное API у себя на бекенде и бац (бац-бац-бацбац!) пользователи твоей системы могут искать всякую фигную и клацать на категории (подкатегории, под-подкатегории) разной шляпы и все это будет быстро-быстро. Только учти, что они основаны на Лусине, а она не транзакционная.
Или, скажем, приперло тебе прикрутить кэширование в свое приложение, т.к. каждый раз ходить в базу данных дорого и ваще не по-пацански и ты такой бац и прикручиваешь какой-нибудь Hazelcast или Redis и кэшируешь данные там, что делает твое приложение быстрее, а волосы мягкими и шелковистыми. Или вот взять пример, решил ты запилить сервис, который будет предлогать оптимальные туристические маршруты (на какой самолет сесть, где купить билет на автобус и как доехать). На всяких PostgreSQL это будет проблематично сделать, да и не для того их разрабатывали. И ты такой бац (бац-бац-бацбац) и уже не прошло и получаса как ты поднимаешь инстанс Neo4j, проектируешь свою модель данных в виде направленного графа и пишешь запросы к графовой базе данных, которая будет тебе за десятки миллисекунд прокладывать оптимальные туристические маршруты для твоих пользователей. Стоит ли говорить, что какая-нибудь реляционная база данных просто сдулась бы на первом запросе на ндцатом джоине выжрав всю память на сервере.
Добра! Пис!
И еще - если бы кто подсказал как полностью профилировать запросы в монго - было бы классно. Сейчас например я не могу в explain найти информацию о том, что происходит в lookup и т.д., только простейшие матчи.
анон
анон
Очевидные индексы очевидны.
Индексы добавил на foreignField, но explain почему-то не показывает информацию по ним вообще, так что я не могу понять - использует он их или нет. Судя по скорости - вроде да
нужно открыть документацию по этой вашей монги и прочесть раздел описывающий профилирование запросов.
Это я все сделал, очевидно, до того как зайти сюда. Нужной мне информации мне это не дало.
Да ничего ты не пытался. Версию монги не указал. А между прочим была целая куча багов по explain, который не мог нормально вывести данные по плану запроса. Да и сам запрос ты не предоставил. Вангую, что у тебя там кривой запрос и explain не туда воткнул ко всему прочему. Инфа соточка так сказать.
>Да ничего ты не пытался.
Понятно, можешь не утруждать себя
Уходи, зеленый
Он все правильно сказал. Ты просто ничего не смыслишь в разработке. Уже давно бы задал вопрос на SO.
лол, буйство семёна
Ну че, удалось получить план запроса? Или ты до сих пор ждешь ответа?
Я уже говорил что план аггрегации получить не проблема, но в нем нет никакой информации о не $match стадиях, просто копия из реквеста.
СО молчит.
Я конкретно ищу информацию о $lookup. В эксплейне - просто показывается копия стадии из реквеста, никаких данных об использовании индекса, длительности выполнения и т.д.
