А есть способы как с этим бороться?Навеяло... Из дневника начальника: сегодня попробовал метод "кнута и пряника", понравилось! Но, пряником бить не удобно, завтра попробую метод "кнута и кнута"...
Это описание альтернативной реализации виртуального столбца, при чем тут JSON индексы?Именно про это я и говорю, это не "механизм индексирования JSON-столбцов", это скорее "случайное стечение обстоятельств", которое "прикостылили" для индексации данных из JSON-столбцов (точнее, части данных из этих столбцов).
SELECT * FROM features
WHERE feature->"$.properties.STREET" = 'MARKET'Этот вариант нам не очень нравится, потому что рано или поздно придётся арендовать новый сервер, настроить его и постоянно поддерживать, а с ростом количества сайтов таких серверов будет всё больше и сложность обслуживания будет расти.Арендуйте облако, чисто гипотетически, его вычислительные ресурсы практически не имеют ограничений.
А создание виртуального столбца на JSON столбец и создание соответствующего индекса, не является разве индексом по JSON столбцу? Забавно конечно.Нет, не является. Давайте приведу несколько примеров уровня "на пальцах"...
{value1: [1, 3, 9, 7, 42]} или того "хуже", значение является объектом... Какой индекс MySQL может нам предложить для подобного рода значений? Из того, что вижу я, наиболее вероятный индекс, это обычный B-tree, толку от использования которого в данном случае, примерно никакого, по крайней мере в условиях реалий MySQL известных мне.Ну не совсем, если до этого приложение работало JSON данными "как есть" (либо с вьюхами, которые доставали поля из JSON средствами базы), то в коде приложения ничего не поменяется, т.к. "создаться" виртуальный столбец, который нигде никак не фигурирует, а индекс при этом будет работать).Не знаю, где именно вы имеете в виду "не фигурирует", у меня лично, этот столбец вполне себе фигурирует, точно так же как и любой другой столбец, в т.ч. в
SELECT * FROM table1 . И индексируется именно "этот" столбец, а не столбец с JSON-данными, на основании которого он [может быть] построен. Более того, не зависимо от того, сколько и каких виртуальных столбцов я сделал и как их индексировал, при обращении напрямую к JSON-полю непосредственно, не затрагивая напрямую этот самый виртуальный столбец, я не вижу, что бы MySQL использовала индекс с виртуального столбца, подозреваю, что это не баг, а В остальном, соглашусь что у каждой БД свое назначение, но хоронить MySQL из-за того, что есть Mongo, которая лучше в плане работы с не реляционными данными, и поднимать еще одну БД, чтобы хранить 3-5 сущностей, как то не огонь.Никоим образом не пытался "похоронить" MySQL, я вообще считаю, что MongoDB, объективно годится для 1-5% проектов, а некоторые её "особенности", (назовём их так) лично мне - объективно не нравятся.
Так что, даже на текущий момент, Mysql JSON-костыль я считаю вполне рабочий инструмент для 40-60% ситуаций, когда нужна работа с неструктурированными данными.Я считаю его вполне работоспособным в 99% ситуаций, когда речь идёт о его использовании с оглядкой на возможные последствия и понимание того, "как оно там работает", даже больше скажу, я крайне рад, что в MySQL появилась поддержка подобного рода данных и ещё больше буду рад, когда в нем работа с этими данными будет построена в полном соотв. с новыми стандартами, так как это повлечет расширение возможностей различных ORM (и им подобных) библиотек в самых разных ЯП и MySQL не станет "тормозом" для реализации такого функционала (который в свою очередь, с вероятностью 99% будет реализован в большинстве других БД, в т.ч. Oracle, PostgreSQL, MS SQL и т.д.) и мир станет чуточку лучше, а в некоторых фреймворках, таких как например Symfony (точнее, я говорю про Doctrine, который в свою очередь является частью Symfony), при попытке сохранить такой тип данных как "массив", он будет сохраняться не как сериализованный в строку объект, а как JSON-данные (например) и т.д.
Нужна возможность именно второго ряда, и чтобы эти два ряда одновременно листались.Мне кажется, если взять почти любой слайдер, и представлять 1 слайд как колонку из двух картинок/элементов/объектов - то проблема решиться сама собой. Примерно вот так:
(красным обозначен каждый отдельный слайд).
Как легко и непринужденно мы вдруг перескочили на Postgres, ну да ладно. Т.е. сначала вы заявляли, что индексы в MySQL нельзя построить по JSON полям, потом оказывается вы имели ввиду по всем свойствам JSON объекта, окей, выкрутились.Нет, никто не выкручивается, давайте говорить предметно. Конкретно по JSON-полю можно построить индекс в MySQL? Нет. Об этом написано в документации. Какие ещё вопросы с этим? Проиндексировать можно значение виртуального столбца, который в свою очередь не имеет никакого ни прямого отношения к JSON-столбцу, там могут быть в буквальном смысле любые данные и к JSON-столбцу это никак не относится. По этому, ещё разок: проиндексировать непосредственно JSON-столбец - нельзя, от слова совсем, т.е. никаким образом, ни таким как в MongoDB, ни таким как в PostgreSQL, ни каким-то ещё.
Я их рассматриваю в разрере структуры хранения данных, и возможности альтернативы использованию Mongo (раз уж вы такой специалист, то может скажется в какой ситуации выгоднее будет монго чем mysql?).То есть по вашему, люди используют MogoDB только по тому, что там были именно данные в формате JSON? "Нереляционные" (назовем их так) типы данных, например, XML появились в MySQL с версии 5.1, появились примерно в 2007г. XML принципиально хуже JSON'а?
Че-то странный вы персонаж, то значит спорите и доказываете, что можно создавать индексы для всех полей JSON объекта, а потом пишите что это на фиг не надо. Дак вы определитесь, надо или нет? Ведь если не надо, то какие претензии к MySQL? А если ответ "в каких то ситуациях нужно", дак в каких то ситуациях и нужно использовать не MySQL.Вы сейчас серьёзно? В MySQL, JSON-поля, это некоторый такой, костыль, который реально годиться для того, что бы хранить какую-то часть документа/записи/строки, которая имеет динамический формат (т.е. заранее неизвестные набор и/или схему данных). MongoDB - это БД которая изначально имеет совершенно другую архитектуру, в т.ч. Монга позволяет индексировать любую структуру документа (или его часть), при этом не изменяя саму структуру, этого документа, как это происходит в MySQL. То есть, если мы вдруг решили, что нам нужен индекс по какому-то новому полю (т.е. связке ключ-значение) - нам не нужно внезапно бежать и переписывать кусок приложения, который теперь будет использовать новое поле (виртуальный столбец, а именно это случиться в MySQL), мы просто строим новый индекс и на работу приложения это никак не влияет. В MySQL не имеет возможности делать ссылки из JSON-данных на другие данные, например так. Есть такая категория людей (разработчиков), которые считают, что если нужна поддержка данных с неопределенной схемой/структурой, то обязательно нужно использовать MongoDB, т.к. хранение "пары строчек" этих самых данных, в поле формата JSON или XML - их почему-то не устраивает (хотя такая возможность покрывает их реальные потребности на 101%). А вы видимо из противоположенной категории людей/разработчиков, которые считают, что "раз MySQL поддерживает JSON, значит, она может полностью заменить MongoDB". Есть масса отличий между MongoDB и MySQL, самых разных, в т.ч. преимуществ и недостатков как у одной БД, так и у другой. И есть ряд проектов, которые по определению будут работать лучше работать с одной БД или с другой, более того, есть ряд проектов которые используют обе этих БД. Вы хотите, что бы я тут лекцию с подробным ТЗ написал, на тему того, в каких случаях MogoDB может быть лучше? Если вы сами понимаете отличия между ними, то немного подумав, представить себе такие проекты - довольно не сложно, а если различия между ними для вас столь не очевидны, о чем мы вообще говорим?
С монго вы судя по всему тоже не работалиДавайте уже оперировать фактами, или чем-то близким к фактам, а не доводами, подкрепленными ничем. Тогда наш диалог будет куда более конструктивным.
Как же сложно с вами общаться. Вы сами пробовали создавать индекс? Каким образом база построит вам индекс по всему JSON полю, которое в принципе может иметь любую структуру?!Например так, один из вариантов индексации JSON-данных. 3 строчки про GIN. Что нам MySQL предоставляет в качестве альтернативы GIN-индексам... дайте подумать... примерно, ничего?
Документацию прочитайте повнимательней, там даже пример по созданию индекса (видимо дальше первого абзаца вы не пошли?)Прочитайте документацию по другим БД, и тогда вопрос "как можно индексировать JSON-поля?" отпадет сам собой.
А теперь вопрос: какого хера, специалист такого уровня как вы, сидит, и несет такую херь?! Или вы слегка преувеличили свои регалии? Или вам просто повезло? Или несмотря на такие заслуги вы херовый специалист? Или вы просто специалист к конкретной области, а считаете себя эрудитом и знатоком во всех областях?Если немного подумать, то херь несёте именно Вы, достаточно взять одно только высказывание, про то, что "MongoDB можно заменить на MySQL без каких либо проблем". Вы берете во внимание исключительно какой-то удобный для подобного утверждения пример, забывая примерно обо всех индивидуальных особенностях этих двух БД. Таких как скорость обработки данных например, общую концепцию работы и так далее. Если бы базы так легко (как вы думаете) взаимозаменялись - достаточно было бы одной БД а MongoDB вероятнее всего, вообще не появилась и вряд ли бы она стала развиваться, а какие-то люди (исходя из вашей логики) - не понимающие прописной истины, которая заключается в том, что в MySQL тоже есть JSON (или возможность туда его добавить) - не стали бы вкладывать сотни тысяч $$$ в развитие MongoDB.
В какой ситуации вам понадобиться создавать индексы по всем ключам JSON поля (или документа в случае с Mongo), если запросы по факту будут делаться по конкретным полям?Это ещё один момент, который показывает крайне не высокий уровень вашей квалификации, который вы так усердно пытаетесь приписать мне. Конкретными - поля (ключи) становятся исключительно в момент запроса, а сама по себе структура - может многократно и динамически меняться в режиме "от случая к случаю". Есть миллион вариантов, при которых нам может понадобиться поиск по динамически выбранному набору полей, который при этом будет "всеми полями" для одного отдельно взятого документа. И индексацию в этом случае, можно проводить так же - динамически, главное делать это с головой, а не бездумно индексировать всё подряд, понимая, для начала, что вообще из себя представляет индекс (физически) и чем нам "грозит" его построение.
Ну вы то видимо знаете раз такую пиздаболию развели.Пиздаболию тут разводите тут исключительно вы в данный момент, причем не стесняясь и оперируя абстрактными понятиями, без какой либо вообще конкретики. В частности, эпитетами вроде:
На высоко-нагруженном сервисе, на net core себя очень неплохо чувствует.На каком-то неведомом сервисе, с какой-то "высокой" исключительно по вашему персональному мнению нагрузкой, как-то там себя чувствует... Очень серьёзный технический аргумент.
Мы говорили про ASP.NET, не конкретно про MVC, а про ASP. Но видимо вы иначе диалог ведете.Мы говорили о том, что багов в Mono - больше чем в винде, а вы называете это "нормально". У вас довольно извращенные представления о "нормальности" чего либо, что-то на уровне "если едет, значит машина".
То что вы никогда не работали с ASP под линуксом, а не пытались поднять более менее что-то серьезное на нем (а может просто не смогли?), это не значит что другие это не делают.Ваше утверждение уровня "как в воду дунул", про неких "других", которые "это делают" - никоим образом не подтверждает ровным счётом ничего, из той же примерно серии "если вы не видели летающих розовых слонов на взлётной полосе, аэродрома, это не значит, что они там не летают".
MongoDB - это документо-ориентированная БД в которой документы представляют из себя JSON файлы. Т.к. MySQL поддерживает JSON поля, то по факту, в общем случае, можно документы (aka таблицы) Mongo, разместить в JSON полях MySQL.MySQL никак не может заменить монгу, хотя бы по той причине, что не может (об этом ниже) индексировать JSON-поля. По такому принципу "замены" о котором Вы говорите - можно БТР заменить тарктором, если к нему прикрутить пулемёт, сходства будут примерно аналогичные.
Документация, видимо поиском лень пользоваться.Открываем документацию, и первой же строчкой читаем:
As noted elsewhere, JSON columns cannot be indexed directly. To create an index that references such a column indirectly, you can define a generated column that extracts the information that should be indexed, then create an index on the generated column, as shown in this exampleИз первого предложения которой становится ясно, что:
Как отмечалось ранее - JSON-колонки не могут быть проиндексированы напрямуючто в свою очередь говорит по факту о том, что они не могут быть проиндексированы вообще. Проиндексировано может быть отдельное значение в виде виртуального столбца. Нужно объяснять, что "виртуальный столбец" и JSON-столбец - это не одно и то же?
Дак собственно выяснять то и нечего, ваша основная претензия это то, что в MySQL не реализован стандарт. По такой логике использовать NoSQL технологии (или прочие), для которых нет стандартов - нельзя?Претензий у меня нет никаких, я просто констатирую факт, который гласит: MySQL и его производные - не поддерживают даже довольно старые стандарты SQL. По такой логике, что дальше делать - каждый для себя решает исключительно сам.
Видимо все ваши работы остались на столе у преподавателей универа.Мои работы до сих пор радуют некоторых крупных заказчиков, как местных так и иностранных (включая международные компании), некоторые из которых входят в ТОП Форбс'а. Некоторых других не менее радуют ряд специалистов, подготовленных лично мной, в т.ч. специалистов международного уровня.
А вы судя по всему интересный собеседник с диким ЧСВА Вы судя по всему отличный практикующий психолог/психиатр, раз так быстро и уверенно оцениваете других людей? Не понимаю, что специалист подобного уровня и главное, - направления, забыл на IT-ресурсе...
Либо функционал такого управления уж очень скудный. Существует ли панель, которая близка к моей задаче? Всё, что мне надо - иметь возможность смотреть логи серверов, запускать, останавливать. Ничего сверхъестественного.Судя по описанию, примерно такой расклад: