Источники данных для LLM
Ну чтобы потом не удивляться цензуре в ответах так называемого искусственного интеллекта.
Показать полностью
1
Серия «ITшное»
0 просмотренных постов скрыто
Интересно - получится съездить в Питер или нет ?
А песок времени - неумолим
Пока нет ответов от программных комитетов конференций.
Обещали на этой неделе. Подождем до завтра.
В принципе - ничего особенного - ну не приняли доклад, значить тема не интересна.
На следующий год, другие конференции будут, да и тема обрастет новыми данными и результатами экспериментов.
В общем - поживем- увидим.
Показать полностью
1
Современный стиль разработки это
Запускать сотни раз в секунду SELECT .. FOR UPDATE на узле репликации для определения роли СУБД :
Это не проблема, это особенность. Приклад таким образом проверяет возможность внесения изменений в БД.
Они безнадежны
Показать полностью
1
Открытый исходник польза или риск
Вопрос непраздный:
Открыть ли код?
Ответ неясный:
Да, может, вот.
Исходник в общем
Свободен весь.
В открытом коде
Полезность есть.
-------
💫 Создано с помощью GigaChat
Показать полностью
1
Преимущества публикации собственных продуктов в формате открытого исходного кода (Open Source)
Тема на подумать, в течении этого года. С одной стороны - есть практические результаты , с другой - интерфейса и юзер мануала нет и очень не хочется тратить время и останавливать эксперименты ради оформления, но , для полноты картины нужны экспериментальные данные на других ландшафтах и нагрузках.
Так, что есть над чем подумать.
Когда программное обеспечение публикуется под открытой лицензией (например, GPL, MIT, Apache), разработчики получают множество значимых преимуществ, которые способствуют повышению эффективности работы команды, снижению рисков и созданию конкурентоспособных решений. Рассмотрим подробнее основные преимущества такой стратегии.
▌ 1. Ускоренная разработка и привлечение сообщества разработчиков
Открытая лицензия привлекает внимание множества программистов по всему миру, многие из которых заинтересованы в участии в интересных проектах и решении сложных технических задач. Благодаря открытому доступу каждый желающий может предложить свои улучшения, исправления ошибок и новые функции — это резко сокращает время, необходимое для доведения продукта до нужного уровня качества. Сообщество участников способно внести значительный вклад не только непосредственно в кодовую базу, но и в документацию, тестирование и другие аспекты разработки.
▌ 2. Повышение надежности и безопасности продукта через коллективный аудит
Программы с открытым исходным кодом подвергаются гораздо большему количеству проверок, чем те, которые закрыты для широкой публики. Чем больше людей видят ваш код, тем выше вероятность обнаружения потенциальных уязвимостей, багов и слабых мест. Это приводит к тому, что итоговый продукт оказывается более стабильным и защищённым, что особенно важно при разработке критически важных систем и приложений.
▌ 3. Формирование активного сообщества поддержки
Участие пользователей и сторонних разработчиков способствует формированию вокруг вашего проекта живого сообщества. Эти люди будут помогать друг другу решать проблемы, делиться опытом и знаниями, что делает использование вашего продукта проще и приятнее. Кроме того, они могут стать потенциальными клиентами вашей коммерческой версии продукта или сервисов, связанных с ним.
▌ 4. Положительное влияние на репутацию компании-разработчика
Организации, публикующие проекты с открытым исходным кодом, часто воспринимаются как передовые и ориентированные на инновации. Публикация успешных проектов демонстрирует технологическую экспертизу компании и её способность разрабатывать высококачественные решения. Компании начинают ассоциироваться с сообществом лучших профессионалов отрасли, что положительно сказывается на их привлекательности среди клиентов и партнёров.
▌ 5. Снижение расходов на инфраструктуру и инструменты разработки
Использование популярных открытых библиотек и фреймворков экономит значительные средства на покупку коммерческих аналогов. Открытость исходников упрощает интеграцию различных компонентов и уменьшает необходимость изобретения велосипедов заново. Более того, наличие большого количества доступных тестов и документации помогает быстрее находить ошибки и оптимизировать производительность системы.
---
▌ Выбор между открытым и закрытым подходами
Перед принятием окончательного решения о публикации проекта стоит учесть следующие факторы:
- Готовность продукта: если проект близок к завершению и достиг определённого уровня стабильности, открытое распространение поможет быстро завершить разработку и вывести продукт на рынок. Однако, если продукт находится на ранних стадиях тестирования или содержит ключевые патенты, лучше сначала тщательно взвесить все риски, связанные с раскрытием технологий конкурентам.
- Экспериментальные и ранние стадии разработки: если технология ещё недостаточно проверена и нуждается в дополнительных исследованиях, временное закрытие доступа позволит защитить ваши идеи и оставить возможность коммерциализации будущих версий.
Итого, прежде чем выбрать путь развития своего проекта, необходимо чётко понимать цели компании, состояние продукта и возможные после
-------
💫 Создано с помощью GigaChat
Показать полностью
1
На тему дня - о хакерах и атаке на Аэрофлот
Кратко - каждый кто верит и тем более распространяет ,генерируемый журналюгами, мутный поток о причинах , исполнителях и деталях события - в лучшем случае наивный идиот, в худшем - сознательный провокатор и враг .
Вывод очень простой - фильтр на любую информацию по поводу события. Проще говоря - полный игнор.
Никто из распространителей информации , не обладает информацией , каждый кто обладает - не распространяет.
В принципе , довольно общая методика по оценке информационного шума , любого крупного события, вполне доказавшая свою эффективность.
Показать полностью
4
Иногда, нейросеть выдаёт вполне себе здравый, хотя и бесполезный текст
▌ Возможности применения рекомендаций нейронных сетей для повышения производительности СУБД PostgreSQL
В последние годы широкое распространение получили методы машинного обучения, применяемые для решения задач анализа данных и автоматизации процессов принятия решений. В частности, одним из перспективных направлений является использование нейронных сетей (НС) для автоматического поиска оптимальных настроек параметров баз данных с целью улучшения их производительности.
СУБД PostgreSQL обладает большим количеством настраиваемых параметров, от правильного выбора которых зависит эффективность работы системы. Традиционные подходы предполагают проведение экспериментов или применение эмпирических правил («best practices»), что требует значительных временных затрат и высокой квалификации специалистов.
Нейронные сети позволяют автоматически выявлять взаимосвязи между параметрами базы данных и показателями ее производительности. Для этого необходимо собрать достаточный объем обучающих данных, включающий различные комбинации значений параметров и соответствующие им показатели времени выполнения запросов, загрузки процессора, объема потребляемой памяти и т.д.
После обучения НС способна генерировать рекомендации по настройке параметров PostgreSQL, минимизируя при этом время отклика и максимизируя пропускную способность системы. Однако следует учитывать ряд ограничений данного подхода:
- зависимость результатов от качества исходных данных;
- сложность интерпретации полученных рекомендаций;
- необходимость регулярного обновления модели вследствие изменения структуры и нагрузки на базу данных.
Таким образом, хотя нейронные сети представляют собой мощный инструмент для оптимизации производительности PostgreSQL, они не могут полностью заменить опыт экспертов и требуют осторожного использования совместно с традиционными методами настройки баз данных.
-------
💫 Создано с помощью GigaChat
Показать полностью
1
Нейросети про ORM
Разработчик удивляется - почему СУБД тормозит при выполнении запросов , написанных ORM ?
-------
💫 Создано с помощью GigaChat
DeepSeek размышляет про ORM
Проблемы SQL-запросов, генерируемых ORM (Object-Relational Mapping), возникают из-за компромисса между удобством разработки и эффективностью работы с базой данных. Вот ключевые проблемы:
1. Проблема N+1 (Избыточные запросы)
- Суть: ORM лениво загружает связанные данные, вызывая множество мелких запросов вместо одного JOIN.
- Пример:
Загрузка 100 пользователей и их заказов:
SELECT * FROM users; -- 1 запрос
SELECT * FROM orders WHERE user_id = 1; -- запрос для каждого пользователя (100 запросов)
2. Неоптимальные JOIN-операции
- ORM может генерировать избыточные `JOIN` или `LEFT JOIN` даже для простых запросов, что замедляет выполнение.
- Риск: "Взрыв" количества строк при соединении таблиц (например, `JOIN` 3 таблицы по 1000 строк → 1 млрд промежуточных строк).
3. Избыточная выборка данных (Over-fetching)
- ORM загружает все поля объекта, даже если нужны 1-2 поля:
SELECT id, name, email, ... -- 20+ полей
FROM users;
- Последствие: Лишняя нагрузка на сеть и СУБД.
4. Сложности с оптимизацией
- ORM абстрагирует SQL, лишая разработчика контроля:
- Невозможно точно указать порядок JOIN.
- Трудно использовать расширенные функции СУБД (например, оконные функции, CTE).
- Ограниченная поддержка сложных условий (`FILTER`, `DISTINCT ON` в PostgreSQL).
5. Генерация монструозных запросов
- Сложные операции (например, агрегация с фильтрацией) могут порождать "мусорный" SQL:
SELECT * FROM (
SELECT *, ROW_NUMBER() OVER (ORDER BY id)
FROM users
WHERE ...
GROUP BY ...
) AS subquery WHERE ... LIMIT 10;
- Такие запросы сложно отлаживать и оптимизировать.
6. Проблемы с производительностью
- ORM не учитывает:
- Индексы: Может не использовать подходящие индексы.
- Кэширование запросов: Динамически генерируемый SQL сложно кэшировать.
- Пакетная вставка: Вместо `INSERT INTO ... VALUES (...), (...)` ORM может создать N одиночных запросов.
7. Импеданс-несоответствие (Object-Relational Impedance Mismatch)
- ORM пытается "натянуть" объектную модель на реляционную БД, что приводит к:
- Некорректной работе с наследованием (стратегии `single_table`, `joined`).
- Проблемам с транзакциями и блокировками.
8. Сложность отладки
- Сгенерированный SQL часто нечитаем (много подзапросов, алиасов).
- Логи ORM "засоряют" консоль, но не дают понимания реальной производительности.
---
Когда избегать ORM?
- Высоконагруженные системы (например, финансовые транзакции).
- Сложные аналитические запросы.
- Системы, где критична предсказуемость выполнения запросов.
Монструозный SQL запрос , сгенерированный ORM.
-------
💫 Создано с помощью GigaChat
YandexGPT размышляет по ORM
Хорошо, мне нужно разобраться с проблемами SQL-запросов, написанных с помощью ORM. Начну с анализа основных аспектов: производительность, сложность запросов, гибкость, оптимизация и безопасность.
Сначала рассмотрю производительность. ORM часто генерируют избыточные запросы или неоптимальные SQL-конструкции, что может привести к снижению производительности. Нужно упомянуть примеры, такие как N+1 проблема.
Далее проанализирую сложность запросов. ORM могут ограничивать возможность написания сложных запросов, требующих специфических SQL-фич, таких как оконные функции или сложные JOIN.
Затем рассмотрю гибкость. ORM абстрагируют работу с базой данных, что может ограничивать возможность тонкой настройки запросов под конкретные задачи.
Оптимизация также важна. ORM могут затруднять оптимизацию запросов, особенно в сложных сценариях, где требуется ручная настройка индексов или других аспектов.
Безопасность — ещё один аспект. Хотя современные ORM обеспечивают защиту от SQL-инъекций, неправильное использование ORM всё ещё может привести к уязвимостям.
Наконец, рассмотрю особенности конкретных ORM, таких как Django ORM и SQLAlchemy, чтобы показать различия в подходах к генерации запросов.
ORM (Object-Relational Mapping) упрощает работу с базами данных, но имеет ряд проблем, связанных с SQL-запросами.
Основные проблемы
Производительность:
ORM могут генерировать избыточные или неоптимальные SQL-запросы, что приводит к снижению производительности. Например, ORM часто используют паттерн N+1, когда для получения связанных данных выполняется множество дополнительных запросов вместо одного эффективного JOIN.
Пример: в Django ORM для получения списка пользователей с их профилями может потребоваться 1 запрос на пользователя, если не использовать select_related.
Сложность запросов:
Некоторые сложные запросы, требующие специфичных SQL-конструкций (например, оконные функции, сложные JOIN или CTE), могут быть трудно или невозможно выразить через ORM. Это ограничивает гибкость при работе с данными.
Гибкость:
ORM абстрагируют работу с базой данных, что может ограничивать возможность тонкой настройки запросов под конкретные задачи. Например, оптимизация запросов для конкретных СУБД (PostgreSQL, MySQL) может быть затруднена.
Оптимизация:
Оптимизация запросов, сгенерированных ORM, может быть сложной из-за отсутствия прямого контроля над SQL. Разработчикам приходится полагаться на встроенные механизмы оптимизации ORM, которые не всегда эффективны.
Безопасность:
Хотя современные ORM обеспечивают защиту от SQL-инъекций за счёт параметризованных запросов, неправильное использование ORM всё ещё может привести к уязвимостям. Например, динамическое построение запросов через конкатенацию строк может обойти встроенные механизмы безопасности.
Интересные факты
N+1 проблема: одна из самых распространённых проблем ORM. Например, в приложении на Django, отображающем список постов с авторами, без использования prefetch_related будет выполнен 1 запрос для списка постов и N запросов для получения авторов каждого поста.
ORM vs Raw SQL: по данным исследований, запросы, написанные вручную, могут быть на 30-50% эффективнее, чем сгенерированные ORM, особенно для сложных аналитических задач.
YandexGPT размышляет о проблемах SQL запросов, написанных ORM
-------
💫 Создано с помощью GigaChat
Показать полностью
2