Главный архитектор СУБД Tarantool покинул Mail.Ru
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(5) Потому, что обычные базы - это плоские таблицы размером NxM, а сетевые базы - это просто запись об объекте, в котором не нужны все поля. Поясню - есть справочник Контрагенты. Для него поля Код, наименование, ИНН, КПП. Каждая запись - неважно нужно ИНН или нет - это все равно строка с полным набором полей. А в сетевой базе можно сделать запись без не нужных полей. Отсюда, по идее, сетевая структура занимает меньше. Ну, если руки не кривые у планировщика базы :-)
(1)NoSQL базы - это как раз СУБД которые изначально проектировались для работы с гигантскими в т.ч. распределёнными объёмами данных - а классчиеские СУБД для этого изначально не проектировались (там другие задачи в приоритете) и сейчас испытывают эволюционные трудности - в попытке притянуть возможность обработки очень больших объёмов данных. Только в среде учета задач (которые сейчас решаются на платформе 1С Предприятие или могли бы решаться в будущем) таких объёмов попросту нет (ну редкие исключения думаю всегда найти можно), т.к. это объёмы которые только начинаются от нескольких терабайт на таблицу, а так могут исчисляться и петабайтами, а в будущем и эксабайтами - условно на таблицу (хотя для NoSQL понятие таблица совсем уж условно). Но, всё-равно - к 1С прикручивают NoSQL базы для решения некоторых аналитических задач (скорее лишь потому, что возможности самой платформы по эффективному взаимодействия с современными реляционными СУБД очень ограничены, а не в силу недостаточного потенциала производительности реляционных СУБД; ну или надо просто подключаться к другим проектам, изначально которые работают не на 1С Предприятие 8)
Вообще - у NoSQL очень большой потенциал, но пока он востребован только в достаточно специфических проектах. Ну и надо не забывать - что у NoSQL есть свои слабые места - и не для всех зада он хорошо подходит. Поэтому, например, SAP HANA - высокопроизводиельная и универсальная учетная система с гибоидной интегрированной прямо в ядро СУБД - включающей как возможности работы с реляционной моделью таблиц, так и колоночную архитектуру. И это здорово. И 1С бы стоило тоже подумать о таком развитии - в будущей 1С Предприятие 9 использовать как работу с реляционной моделью (причём, например, MS SQL Server умеет строить колоночные индексы прямо поверх реляционной БД), так и более продвинутые возможности NoSQL - например сетевую архитектуру (или документную) - чтобы можно было для разных задач прямо в платформе 1С Предприятие выбирать разные виды метаданных. Но это только мечты... которые у конкурентов уже становятся реальностью
Вообще - у NoSQL очень большой потенциал, но пока он востребован только в достаточно специфических проектах. Ну и надо не забывать - что у NoSQL есть свои слабые места - и не для всех зада он хорошо подходит. Поэтому, например, SAP HANA - высокопроизводиельная и универсальная учетная система с гибоидной интегрированной прямо в ядро СУБД - включающей как возможности работы с реляционной моделью таблиц, так и колоночную архитектуру. И это здорово. И 1С бы стоило тоже подумать о таком развитии - в будущей 1С Предприятие 9 использовать как работу с реляционной моделью (причём, например, MS SQL Server умеет строить колоночные индексы прямо поверх реляционной БД), так и более продвинутые возможности NoSQL - например сетевую архитектуру (или документную) - чтобы можно было для разных задач прямо в платформе 1С Предприятие выбирать разные виды метаданных. Но это только мечты... которые у конкурентов уже становятся реальностью
Ну вот, единственный приличный продукт что у мэйл ру намечался их покинул :). P.S. интересно когда 1С даст нам возможность отдельные таблицы располагать в сторонних СУБД.... Без ODBC и внешних источников....
(8) дата акселератор ты о нем что ли? Ну это встроенная в платформу СУБД. А нам бы возможность использовать сторонние. Типа выбрал для справочника СУБД, ввёл настройки подключения и оно туда переехало. Хочешь - используй свою. Переопредели только методы доступа :). Вот зажили бы
(10)Да, прикольная была бы фишка... может когда-нибудь и будет... ну или надо свою учетную платформу строить - универсально расширяемую!
Но, всё-таки, вероятно, если и выйдет, когда-нибудь 1С Предприятие 9 - то к тому времени она уже должна сать сервис-ориентированной учетной системой. А у таких систем блок реализации бизнес логики - бакэнд - привращается в мидлваре - и не взаимодействует напрямую с СУБД (впрочем, как и с фронтэндом тоже) - весь процесс организован через сетевые вызовы (условно через - web-сервисы - но не обязательно через этот механизм) - суть в том, всё взаимодействие идёт через объектно-ориентированный API движка, заточенного под массовое распределённое обслуживание. И этот API на стороне уже бакэнд-сервиса конфигурируется под своего потребителя - обычно декоративно, но внутренние скрипты (которые будут применяться при обработке банных на стороне СУБД) туда тоже загружать можно. И приложению с бизнеслогикой мидлваре уже не известно - какая там реально СУБД находится и какая там вообще архитектура хранения и обработки - для неё бакэнд-сервис - это чёрныйы ящик, который. правда сконфигурирован под решение задач бизнеслогики.
Тогда - можно будет конфигурировать такой бакэнд отдельно - от движка, обрабатываающего инструкции бизнес логики учетной системы на стороне мидлваре сервера. То есть архитектура условно такая:
1. Фронтэнл- с корее всего web-клиент
2. Web-сервер - транспортный сервис
3. Мидлваре - Сервер бизнес-приложения - тут вся внутренняя бизнеслогика
4. Бакэнд-сервис - управляющий СУБД (возможно распределённый)
5. СУБД - класстер или иная распределённая структура
Но, всё-таки, вероятно, если и выйдет, когда-нибудь 1С Предприятие 9 - то к тому времени она уже должна сать сервис-ориентированной учетной системой. А у таких систем блок реализации бизнес логики - бакэнд - привращается в мидлваре - и не взаимодействует напрямую с СУБД (впрочем, как и с фронтэндом тоже) - весь процесс организован через сетевые вызовы (условно через - web-сервисы - но не обязательно через этот механизм) - суть в том, всё взаимодействие идёт через объектно-ориентированный API движка, заточенного под массовое распределённое обслуживание. И этот API на стороне уже бакэнд-сервиса конфигурируется под своего потребителя - обычно декоративно, но внутренние скрипты (которые будут применяться при обработке банных на стороне СУБД) туда тоже загружать можно. И приложению с бизнеслогикой мидлваре уже не известно - какая там реально СУБД находится и какая там вообще архитектура хранения и обработки - для неё бакэнд-сервис - это чёрныйы ящик, который. правда сконфигурирован под решение задач бизнеслогики.
Тогда - можно будет конфигурировать такой бакэнд отдельно - от движка, обрабатываающего инструкции бизнес логики учетной системы на стороне мидлваре сервера. То есть архитектура условно такая:
1. Фронтэнл- с корее всего web-клиент
2. Web-сервер - транспортный сервис
3. Мидлваре - Сервер бизнес-приложения - тут вся внутренняя бизнеслогика
4. Бакэнд-сервис - управляющий СУБД (возможно распределённый)
5. СУБД - класстер или иная распределённая структура
(18) Ну, кому нужен высоконадёжный доступ - тем нужно использовать системы резервирования - вот 1С Предприятие 8 сейчас вообще не умеет использовать системы резрвирования ресурсов в СУБД - а если бы можно было вклиниться между бизнес логикой кластера сервера приложений и самой СУБД - то такую прослойку можно было бы организовать - когда одна СУБД падает - она подключает другую.
Ну а если не делать резеврирование - то можно было бы просто отключать предоставление доступа к справочнику - до решения проблемы - да, часть работы встала бы - кому важно - те пусть резервирование обеспечивают, остальные - пусть работают пока с другими задачами.
А сейчас - случись такое в основной СУБД что будет - по любому встанут все в узел (будут рабоать только в других распределённых узлах).
Ну а если не делать резеврирование - то можно было бы просто отключать предоставление доступа к справочнику - до решения проблемы - да, часть работы встала бы - кому важно - те пусть резервирование обеспечивают, остальные - пусть работают пока с другими задачами.
А сейчас - случись такое в основной СУБД что будет - по любому встанут все в узел (будут рабоать только в других распределённых узлах).
(7)Знаете - в мире учета, далёком от 1С - это вообще-то обычная практика - когда для решения разного рода задач применяют разные СУБД, но там - чаще всего так же как в 1С - одна система не умеет универсально со всеми СУБД работать - и там применяется принцип интеграции - разного рода задачи решаются в своих отдельных учетных системах - которые между друг другом интегрируются - и в этом, то как раз, не ничего плохого. Вот, почему такая практика не прижилась для платформы 1С Предприятие - мне непонятно - тут друг с другом интегрируются в основном только сами конфигурации 1С, и намного реже - другие продукты - обычно через на коленке прикрученную к 1С шину транспорта данных - с которой эти другие продукты как раз уже из коробки умеют эффективно взаимодействовать!
Так может и 1С Платформу не стоит использовать как микроскоп, которым нужно построить дом и забить сваи! А нужно организовать лабораторию при стройке - где под микроскопом можно изучить гвоздики или структуру кирпичей, а сваи всё-таки забивать копером? То есть - для 1С Предприятия нужны более эффективные средства интеграции с известными шинами транспорта данных? По сути, тут всё можно было бы решить и внешними компонентами и кодом на языке 1С - вот только порознь - это опять будет прикручивание на коленке - нужна стандартизация... ну и гибкость в выборе нестандартных провайдеров взаимодействия - кому надо будет...
Так может и 1С Платформу не стоит использовать как микроскоп, которым нужно построить дом и забить сваи! А нужно организовать лабораторию при стройке - где под микроскопом можно изучить гвоздики или структуру кирпичей, а сваи всё-таки забивать копером? То есть - для 1С Предприятия нужны более эффективные средства интеграции с известными шинами транспорта данных? По сути, тут всё можно было бы решить и внешними компонентами и кодом на языке 1С - вот только порознь - это опять будет прикручивание на коленке - нужна стандартизация... ну и гибкость в выборе нестандартных провайдеров взаимодействия - кому надо будет...
Вопросы с вознаграждением
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|