Главный архитектор СУБД Tarantool покинул Mail.Ru

0. Infostart 12.09.19 13:55 Сейчас в теме
Главный архитектор СУБД Tarantool Константин Осипов заявил, что уходит из команды поддержки базы данных в Mail.Ru. Распалась и команда мейнтейнеров – людей, которые имеют право вносить изменения в основную ветку продукта.

Перейти к новости

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. protexprotex 129 12.09.19 14:15 Сейчас в теме
И объем базы должен быть в разы меньше чем у SQL - СУБД
5. Светлый ум 269 13.09.19 05:22 Сейчас в теме
(1) Почему меньше, из-за реляционной структуры?
6. protexprotex 129 13.09.19 08:08 Сейчас в теме
(5) Потому, что обычные базы - это плоские таблицы размером NxM, а сетевые базы - это просто запись об объекте, в котором не нужны все поля. Поясню - есть справочник Контрагенты. Для него поля Код, наименование, ИНН, КПП. Каждая запись - неважно нужно ИНН или нет - это все равно строка с полным набором полей. А в сетевой базе можно сделать запись без не нужных полей. Отсюда, по идее, сетевая структура занимает меньше. Ну, если руки не кривые у планировщика базы :-)
11. Darklight 27 13.09.19 13:24 Сейчас в теме
(1)NoSQL базы - это как раз СУБД которые изначально проектировались для работы с гигантскими в т.ч. распределёнными объёмами данных - а классчиеские СУБД для этого изначально не проектировались (там другие задачи в приоритете) и сейчас испытывают эволюционные трудности - в попытке притянуть возможность обработки очень больших объёмов данных. Только в среде учета задач (которые сейчас решаются на платформе 1С Предприятие или могли бы решаться в будущем) таких объёмов попросту нет (ну редкие исключения думаю всегда найти можно), т.к. это объёмы которые только начинаются от нескольких терабайт на таблицу, а так могут исчисляться и петабайтами, а в будущем и эксабайтами - условно на таблицу (хотя для NoSQL понятие таблица совсем уж условно). Но, всё-равно - к 1С прикручивают NoSQL базы для решения некоторых аналитических задач (скорее лишь потому, что возможности самой платформы по эффективному взаимодействия с современными реляционными СУБД очень ограничены, а не в силу недостаточного потенциала производительности реляционных СУБД; ну или надо просто подключаться к другим проектам, изначально которые работают не на 1С Предприятие 8)

Вообще - у NoSQL очень большой потенциал, но пока он востребован только в достаточно специфических проектах. Ну и надо не забывать - что у NoSQL есть свои слабые места - и не для всех зада он хорошо подходит. Поэтому, например, SAP HANA - высокопроизводиельная и универсальная учетная система с гибоидной интегрированной прямо в ядро СУБД - включающей как возможности работы с реляционной моделью таблиц, так и колоночную архитектуру. И это здорово. И 1С бы стоило тоже подумать о таком развитии - в будущей 1С Предприятие 9 использовать как работу с реляционной моделью (причём, например, MS SQL Server умеет строить колоночные индексы прямо поверх реляционной БД), так и более продвинутые возможности NoSQL - например сетевую архитектуру (или документную) - чтобы можно было для разных задач прямо в платформе 1С Предприятие выбирать разные виды метаданных. Но это только мечты... которые у конкурентов уже становятся реальностью
2. 3vs 12.09.19 14:57 Сейчас в теме
Как бы не получилось как в песне - "дан приказ ему на запад...".
А что вполне себе, у percona.com появится ещё одна поддерживаемая вместе с Percona Server for MongoDB
и Percona Server for Tarantool.
3. sergro 13.09.19 03:04 Сейчас в теме
(1 И какие ограничения на объем базы NoSQL?
9. protexprotex 129 13.09.19 10:30 Сейчас в теме
(3) Ограничения - так только по мощности сервера и объема хранилища. Но чем меньше база, тем быстрее поиск. Даже при использовании индексов все равно меньше база - будет быстрее искать.
4. nytlenc 13.09.19 04:44 Сейчас в теме
@Mail.Ru иди Амиго дописывай... Tarantool ага.. Пошутили?
7. comol 4554 13.09.19 09:03 Сейчас в теме
Ну вот, единственный приличный продукт что у мэйл ру намечался их покинул :). P.S. интересно когда 1С даст нам возможность отдельные таблицы располагать в сторонних СУБД.... Без ODBC и внешних источников....
KazanKokos; acanta; iliabvf; testnv0; +4 Ответить
8. Evil Beaver 7005 13.09.19 10:01 Сейчас в теме
(7) там завезли новый механизм, что-то типо "копии баз данных" или как-то так, короче репликация но встроенная в платформу. Я подробнее не копал еще.
10. comol 4554 13.09.19 11:19 Сейчас в теме
(8) дата акселератор ты о нем что ли? Ну это встроенная в платформу СУБД. А нам бы возможность использовать сторонние. Типа выбрал для справочника СУБД, ввёл настройки подключения и оно туда переехало. Хочешь - используй свою. Переопредели только методы доступа :). Вот зажили бы
12. Darklight 27 13.09.19 13:25 Сейчас в теме
(10)Да, прикольная была бы фишка... может когда-нибудь и будет... ну или надо свою учетную платформу строить - универсально расширяемую!

Но, всё-таки, вероятно, если и выйдет, когда-нибудь 1С Предприятие 9 - то к тому времени она уже должна сать сервис-ориентированной учетной системой. А у таких систем блок реализации бизнес логики - бакэнд - привращается в мидлваре - и не взаимодействует напрямую с СУБД (впрочем, как и с фронтэндом тоже) - весь процесс организован через сетевые вызовы (условно через - web-сервисы - но не обязательно через этот механизм) - суть в том, всё взаимодействие идёт через объектно-ориентированный API движка, заточенного под массовое распределённое обслуживание. И этот API на стороне уже бакэнд-сервиса конфигурируется под своего потребителя - обычно декоративно, но внутренние скрипты (которые будут применяться при обработке банных на стороне СУБД) туда тоже загружать можно. И приложению с бизнеслогикой мидлваре уже не известно - какая там реально СУБД находится и какая там вообще архитектура хранения и обработки - для неё бакэнд-сервис - это чёрныйы ящик, который. правда сконфигурирован под решение задач бизнеслогики.
Тогда - можно будет конфигурировать такой бакэнд отдельно - от движка, обрабатываающего инструкции бизнес логики учетной системы на стороне мидлваре сервера. То есть архитектура условно такая:
1. Фронтэнл- с корее всего web-клиент
2. Web-сервер - транспортный сервис
3. Мидлваре - Сервер бизнес-приложения - тут вся внутренняя бизнеслогика
4. Бакэнд-сервис - управляющий СУБД (возможно распределённый)
5. СУБД - класстер или иная распределённая структура
14. nomad_irk 55 13.09.19 13:49 Сейчас в теме
(10)Ага, доступ пропал по какой-либо причине - вот забегали бы :)
15. Darklight 27 13.09.19 13:55 Сейчас в теме
16. nomad_irk 55 13.09.19 13:57 Сейчас в теме
(15) О справочнике 1С в сторонней СУБД.
17. Darklight 27 13.09.19 14:04 Сейчас в теме
(16)Я просто не понял, где здесь будет усиление проблемы? Упадёт универсальная система взаимодействия с СУБД или проприетарная - никакой разницы - все забегают в любом случае
18. nomad_irk 55 13.09.19 14:06 Сейчас в теме
(17)Эээ.....я говорю про случай, когда "основная" СУБД, в которой размещается большинство данных 1С будет работать, а СУБД, в которой размещается отдельный справочник 1С будет не доступна по какой-то причине.
19. Darklight 27 13.09.19 14:10 Сейчас в теме
(18) Ну, кому нужен высоконадёжный доступ - тем нужно использовать системы резервирования - вот 1С Предприятие 8 сейчас вообще не умеет использовать системы резрвирования ресурсов в СУБД - а если бы можно было вклиниться между бизнес логикой кластера сервера приложений и самой СУБД - то такую прослойку можно было бы организовать - когда одна СУБД падает - она подключает другую.
Ну а если не делать резеврирование - то можно было бы просто отключать предоставление доступа к справочнику - до решения проблемы - да, часть работы встала бы - кому важно - те пусть резервирование обеспечивают, остальные - пусть работают пока с другими задачами.
А сейчас - случись такое в основной СУБД что будет - по любому встанут все в узел (будут рабоать только в других распределённых узлах).
20. iliabvf 13.09.19 20:55 Сейчас в теме
(10)
Типа выбрал для справочника СУБД, ввёл настройки подключения и оно туда переехало. Хочешь - используй свою. Переопредели только методы доступа :). Вот зажили бы
Прикрепленные файлы:
21. iliabvf 13.09.19 20:56 Сейчас в теме
(10) выгружал во внешнюю MS SQL только 1 справочник, реализовано уже давно в 8.3.14
13. Darklight 27 13.09.19 13:37 Сейчас в теме
(7)Знаете - в мире учета, далёком от 1С - это вообще-то обычная практика - когда для решения разного рода задач применяют разные СУБД, но там - чаще всего так же как в 1С - одна система не умеет универсально со всеми СУБД работать - и там применяется принцип интеграции - разного рода задачи решаются в своих отдельных учетных системах - которые между друг другом интегрируются - и в этом, то как раз, не ничего плохого. Вот, почему такая практика не прижилась для платформы 1С Предприятие - мне непонятно - тут друг с другом интегрируются в основном только сами конфигурации 1С, и намного реже - другие продукты - обычно через на коленке прикрученную к 1С шину транспорта данных - с которой эти другие продукты как раз уже из коробки умеют эффективно взаимодействовать!
Так может и 1С Платформу не стоит использовать как микроскоп, которым нужно построить дом и забить сваи! А нужно организовать лабораторию при стройке - где под микроскопом можно изучить гвоздики или структуру кирпичей, а сваи всё-таки забивать копером? То есть - для 1С Предприятия нужны более эффективные средства интеграции с известными шинами транспорта данных? По сути, тут всё можно было бы решить и внешними компонентами и кодом на языке 1С - вот только порознь - это опять будет прикручивание на коленке - нужна стандартизация... ну и гибкость в выборе нестандартных провайдеров взаимодействия - кому надо будет...
22. Kireno 19.09.19 16:40 Сейчас в теме
Тарантул и Оракл это как Жигули и Мерседес?
Оставьте свое сообщение
Вопросы с вознаграждением