Программирование[9]

[JuJeu]

GoldRobot написал 4 минуты назад:

Это да. Только никто не понимает о чем я и думают о самом скрипте... 

 

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

Изменено 23 июня 2020 пользователем JuJeu

[nobodies]

GoldRobot написал 8 минут назад:

Пострес тоже давно умеет.

И индексы по этой "один хуй строке-колонке" запилит.

 

Джон с 500 ключами, каждый из которых на столько важен что его пришлось в отдельную колонку заносить.

На лицо ошибка в инструменте, а не в том кто им пользуется!

 

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

Я понимаю что даже лучшие ошибаются, но как думаешь: каковы шансы облажаться у проектировщиков бд во главе с олегом бартуновым на комерческом проекте? Почему то у меня к таким людям как олег куда больше доверия (не слепого), чем к людям со стажем кодинга меньше 10 лет

[Darkd3ad]

т.е. in-memory бд решают проблему засунули хуй в строку, а надо было в колонку?

 

В in-memory бд часть данных хранится в строчном формате, а часть в колоночном (причем часть данных в колоночном формате хранится и обрабатывается в оперативной памяти локального пк или че)?

[nobodies]

GoldRobot написал 10 минут назад:

Это да. Только никто не понимает о чем я и думают о самом скрипте... 

 

Бей ниже пояса и называй яской: яваскрипт обджект нотейшн

[E1azor]

JuJeu написал 16 минут назад:

E1azor написал 22 минуты назад:

JuJeu написал 26 минут назад:

E1azor написал 28 минут назад:

А есть такая хуйня чтобы из данной бд сделать эквивалентную, но, скажем, чтобы определённые запросы работали быстрее (дан список запросов с коэффициентами важности )?

остановись

Чел, я просто поинтересовался. Этой задачей никому ебать мозга не собираюсь, слишком сложно.

А вот бд для буковок давно пора уже сформулировать

есть различные способы оптимизации sql запросов. делаешь профилирование и дальше по своим навыкам начинаешь оптимизировать. начиная с добавления нужных индексов и заканчивая разделением бд на запись и чтение. Но в любом случае, как мы раньше говорили (пару месяцев назад) есть in-memory хранилища, где можно хранить сериализованные объекты в памяти и дальше -> маршалинг (это процесс передачи сериализованных объектов по стеи) -> десериализация (есть определенные орм, которые делают касты из объекта и в объект). Это уже известные проблемы и уже есть куча решений.

это наверно не автоматические действия

я имел в виду процедура типа нажал кнопку и всё: бд полностью перестроилась и оптимизировалась под мой набор важных запросов

а то что ты написал похоже на каменный век из говна и палок

 

КС грамматики же хорошо оптимизируются, правда, @JuJeu ?

 

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

Изменено 23 июня 2020 пользователем E1azor

[JuJeu]

Darkd3ad написал 1 минуту назад:

т.е. in-memory бд решают проблему засунули хуй в строку, а надо было в колонку?

 

В in-memory бд часть данных хранится в строчном формате, а часть в колоночном (причем часть данных в колоночном формате хранится и обрабатывается в оперативной памяти локального пк или че)?

Я не читал ссылку, но предположу, что данные хранятся в памяти, а дальше в момент запросы происходят касты в нужную структуру (структура зависит от сервиса, который спрашивает данные).

В in-memory механизм используют различные кэш-системы. Почитай про тот же redis или memcached.

[nobodies]

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

[JuJeu]

E1azor написал 4 минуты назад:

JuJeu написал 15 минут назад:

E1azor написал 21 минуту назад:

JuJeu написал 25 минут назад:

E1azor написал 27 минут назад:

А есть такая хуйня чтобы из данной бд сделать эквивалентную, но, скажем, чтобы определённые запросы работали быстрее (дан список запросов с коэффициентами важности )?

остановись

Чел, я просто поинтересовался. Этой задачей никому ебать мозга не собираюсь, слишком сложно.

А вот бд для буковок давно пора уже сформулировать

Показать больше  

есть различные способы оптимизации sql запросов. делаешь профилирование и дальше по своим навыкам начинаешь оптимизировать. начиная с добавления нужных индексов и заканчивая разделением бд на запись и чтение. Но в любом случае, как мы раньше говорили (пару месяцев назад) есть in-memory хранилища, где можно хранить сериализованные объекты в памяти и дальше -> маршалинг (это процесс передачи сериализованных объектов по стеи) -> десериализация (есть определенные орм, которые делают касты из объекта и в объект). Это уже известные проблемы и уже есть куча решений.

это наверно не автоматические действия

я имел в виду процедура типа нажал кнопку и всё: бд полностью перестроилась и оптимизировалась под мой набор важных запросов

а то что ты написал похоже на каменный век из говна и палок

 

КС грамматики же хорошо оптимизируются, правда, @JuJeu ?

 

ты уже рассказываешь про движок, в котором и происходят такие оптимизации. У тебя есть оптимизации, которые ты можешь руками сделать и есть, которые движок дб делает.

nobodies написал 1 минуту назад:

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

инвалидация кэша в event based системе. как тебе такой панч?

@E1azor вот он про ещё одну фичу говорит. первый запрос долгий, а уже последующие быстрее (оптимизированы и что-то закэшировано).

Изменено 23 июня 2020 пользователем JuJeu

[nobodies]

Только я в базах почти не шарю: как то исторически сложилось что они всегда были вне зоны моей отвественности, только в универе tsql и oracle трогал

[Darkd3ad]

JuJeu написал 2 минуты назад:

Darkd3ad написал 7 минут назад:

т.е. in-memory бд решают проблему засунули хуй в строку, а надо было в колонку?

 

В in-memory бд часть данных хранится в строчном формате, а часть в колоночном (причем часть данных в колоночном формате хранится и обрабатывается в оперативной памяти локального пк или че)?

Я не читал ссылку, но предположу, что данные хранятся в памяти, а дальше в момент запросы происходят касты в нужную структуру (структура зависит от сервиса, который спрашивает данные).

В in-memory механизм используют различные кэш-системы. Почитай про тот же redis или memcached.

Т.е. предполагаешь, что в случае in-memory систем происходит запрос из строчной бд, после чего происходит преобразование в памяти локального ПК в колоночный формат и дальнейшие действия происходят в памяти локального ПК,  что в общей сумме ускоряет работу?

 

Или сами таблицы частично хранятся поколоночно без преобразований?

[Just.Doit]

Darkd3ad написал 1 час назад:

JuJeu написал 1 час назад:

Darkd3ad написал 1 час назад:

т.е. in-memory бд решают проблему засунули хуй в строку, а надо было в колонку?

 

В in-memory бд часть данных хранится в строчном формате, а часть в колоночном (причем часть данных в колоночном формате хранится и обрабатывается в оперативной памяти локального пк или че)?

Я не читал ссылку, но предположу, что данные хранятся в памяти, а дальше в момент запросы происходят касты в нужную структуру (структура зависит от сервиса, который спрашивает данные).

В in-memory механизм используют различные кэш-системы. Почитай про тот же redis или memcached.

Т.е. предполагаешь, что в случае in-memory систем происходит запрос из строчной бд, после чего происходит преобразование в памяти локального ПК в колоночный формат и дальнейшие действия происходят в памяти локального ПК,  что в общей сумме ускоряет работу?

 

Или сами таблицы частично хранятся поколоночно без преобразований?

ты заебал

найди уже 5 статей  по интересующим тебя темам и читай их

потом еще и еще

[Kant]

nobodies написал 2 часа назад:

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

 

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

 

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

 

Апд: нет, монгу тоже не надо использовать на каждом проекте

 

это что ж за говнокод должен быть, что у тебя 1 объект имеет 500 простых полей на одном уровне?

 

[Kant]

Darkd3ad написал 2 часа назад:

JuJeu написал 2 часа назад:

Kant написал 2 часа назад:

 

Darkd3ad написал 2 часа назад:

@Kant т.е. есть совмещенные БД? как например сейчас есть совмещенные бд row-column

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

GoldRobot написал 2 часа назад:

Конструктор бд есть в каждой крупной компании. Называется database developer, ага.

я не про профессию, а ПО с подобным функционалом.

есть такое?

ваще не вдупляю про какие совмещенные бд ты говоришь

похоже он про row-colunb based DB 

ну у оракл я видел какую-то хуйню типа oracle in-memory, где как я понимаю таблицы и колончные, и строчные

 

кажется о чем-то об этом говорю

 

шта

ин мемори это вообще отдельная штука

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

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

все OLAP базы со своими аналитическими запросами срать хотели на индивидуальные строки по большей части. Они выберут 100500 строк за промежуток времени и начнут колонки друг на друга делить, им выгодней данные в колонках в этом случае располагать, тк данные часто денормализованы для скорости и получаются гигантские таблицы из которых нужны только 5-10 колонок на запрос

[sonac]

https://diginomica.com/hsbc-moves-65-relational-databases-one-global-mongodb-database

 

на тему того, что sql > all

 

пацаны ушли со своих реляционок и их волосы стали гладкими и шелковистыми. у меня друг работал на проекте HSBC и по его словам, там еще 5 лет назад было достаточно много носкл.

 

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

[E1azor]

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

наверно ещё серваки без кд затаривают

уроды ёбаные

[Kant]

нахуя им 65 раздельных баз?

офк они заебались менеджить всю эту хуйню, ща решили лупануть всё в одну, так хули было с реляционными так не сделать лул

 

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

от одной сраной таблицы операций будут связи на сотни 2 таблиц сходу

удачи джоинить всё это в носкле

[GoldRobot]

Kant написал 22 минуты назад:

nobodies написал 2 часа назад:

 

это что ж за говнокод должен быть, что у тебя 1 объект имеет 500 простых полей на одном уровне?

 

Да там не говнокод, а просто человек он не понял о чем пример был.

Олег расказал как они занимались проектом где у каждого объекта определенного класса может быть свой набор полей. Когда прикинули у них получилось 500 штук. Из них только по 5 являются общими, и только по ним нужен поиск, все остальное в довесок идет.

Собственно, для того что бы это реализовать они запилили прародитель джейсона в постресе, hstore. А дальше он расказывает как они пришли к jsonb типу и насколько он няшный.

[GoldRobot]

Kant написал 4 минуты назад:

нахуя им 65 раздельных баз?

офк они заебались менеджить всю эту хуйню, ща решили лупануть всё в одну, так хули было с реляционными так не сделать лул

 

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

от одной сраной таблицы операций будут связи на сотни 2 таблиц сходу

удачи джоинить всё это в носкле

Да это как всегда.

 

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

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

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

[nobodies]

Kant написал 34 минуты назад:

nobodies написал 2 часа назад:

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

 

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

 

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

 

Апд: нет, монгу тоже не надо использовать на каждом проекте

 

Показать больше  

это что ж за говнокод должен быть, что у тебя 1 объект имеет 500 простых полей на одном уровне?

 

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

[E1azor]

nobodies написал 1 минуту назад:

Kant написал 37 минут назад:

nobodies написал 2 часа назад:

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

 

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

 

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

 

Апд: нет, монгу тоже не надо использовать на каждом проекте

 

Показать больше  

это что ж за говнокод должен быть, что у тебя 1 объект имеет 500 простых полей на одном уровне?

 

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

русский язык почитай

 

"ю хэв" означает "имеется"

Изменено 23 июня 2020 пользователем E1azor