Если условия позволяют использовать minimally logged (пустая таблица с ключом, индексы строим позже, заливка в порядке кластерного ключа), то даже простой INSERT SELECT отрабатывает так же быстро, как BULK.
Давайте сравнивать яблоки с яблоками, а не с теннисными мячиками. В вашем примере можно замерить передачу данных по сети и снова окажется, что она быстрее у РСУБД за счет в разы более компактного табличного формата. Сравнивать время выполнения BULK INSERT корректно не с получением сигнала о передаче пакета (это легко изобразить с SqlBulkCopy.WriteToServerAsync), а с реальной вставкой данных. То, что она не гарантирована - следующий уровень игры.
Уррра! Легко загрузили все данные. Но, блин, что-то с запросами совсем беда...
Переходим на Постгрес - это хоть и не молодежно, но модно и, типа, бесплатно
Ура! Запросы, наконец, стало удобно писать, язык человеческий. Но, блин, почему так медленно? Неужели Оракл и Микрософт не зря хотят денег за свои СУБД с оптимизаторами, вылизанными за десятки лет?
Нет, СУБД из Big-3 нам не потянуть, придется перенести часть вычислений из запросов и хранимых процедур в код служб...
Мне кажется, или в статье действительно не хватает инженерной конкретики? Например, вместо обсуждения производимых пользователем операций, затрат на поддержку (в терминах компонентов, строк кода, связей, сложности, наконец) и интеграцию в вариантах "оставим три среды" и "сделаем одну", тематика сползает на "что отличало её от нас, это эмоциональная привязанность к решению".
Встречный вопрос: "Как использовать вашу библиотеку с custom allocators?"
Обычно аллокатор вставляют в заголовок. Возможно, ваши классы совсем не работают с памятью, ничего не создают и не удалают, тогда, действительно, можно обойтись без него.
Аллокаторы рекомендуются к использованию во всех template-объявлениях, если они представляют собой библиотеку. Никто ведь не знает заранее, когда, кем и с какой целью твой библиотечный код будет использован. По умолчанию просто ставим std::allocator с чувством заботы о ближних.
Быстродействие LibreOffice на "5", это не шутка? Стоит начать редактировать текстовые блоки в презентации на 20 слайдов с задержкой в 2 секунды на отрисовку или рукводство-книгу на 150 страниц...
В тексте не хватает реалистичности, для чего необходимо уточнить технологические ниши таких Вась. Если речь об автоматизации, то Васи должны разбираться в потрохах тиражируемых ERP-систем. Широкое поле для деятельности Вась дают монстры типа SAP, но и 1С тоже сойдет. Выходя за рамки автоматизации, экспертиза СУБД-решений также будет хорошей иллюстрацией, десять тысяч параметров конфигурации Оракла - это вам не масло в мотор залить. Если же речь идет о полностью внутренних вертикальных решениях с тоннами легаси-кода, то Васи тут не помогут.
Принцип garbage in - garbage out никто не отменял. Если вы не можете контролировать чистоту данных при записи в БД, то вам придется делать это потом, при каждом запросе на их извлечение из БД. Это раз. Для подхода "храним все, что прилетает" у вас нет разделения "болота данных" и витрин, это два. 1000 пользователей никогда не работают одновременно над всеми данными, это три.
Не только можно, это очень популярная архитектура примерно с середины 1990-х годов - использование процедурного расширения SQL СУБД в качестве сервера приложений с тонким клиентом. Примеры, навскидку, "Босс-компания" (не путать с "Босс-корпорацией") и Ultima-Seller, перетекший в открытый код. Подробнее по ссылке.
Основная проблема того, что называют NoSQL - в непроработанности моделей данных. Зная, что практически все они были известны в дореляционную эпоху (к моменту "великого спора" Кодда с Бахманом их было известно более 40), можно с основанием говорить о неполноте и даже о неполноценности.
Полнота SQL иллюстрируется просто. SQL-запрос над множеством возвращает множество, которое может быть обработано следующим SQL-запросом или подзапросом. В NoSQL даже созданные сверху SQL-подобные языки так не могут, и проблема не в языках, а в модели данных и замкнутости операций. Для выборки, которую не обработать одним запросом, нужно писать программу (здравствуй, Питон). Исключение - KeySQL, где эта теоретическая проблема решена.
Вариант 3, тоже распространенный. Делали проект для заказчика, но по дороге поняли, что можно продать другим с небольшими изменениями. Проект превратился в продукт.
Первый вопрос разработчики задают сами себе: "Мне/нам это нужно?" Найдя рациональные аргументы на этом начальном уровне, можно подступаться к следующему. И начинают обычно с "Нужно ли вообще развивать продукт или можно ограничиться поддержкой?"
Мне не раз приходилось помогать клиентам переносить легаси системы объемом около 1М строк и десятками сторонних компонентов с Д4 и Д7 на 10.х. Дело это небыстрое, но ваше объяснение из разряда "кто не хочет, ищет причины, кто хочет - средства"
Название WNT (Windows NT) - инкремент букв в аббревиатуре VMS.
Это была шутка, надеюсь? Вроде до 1 апреля еще больше недели.
Если условия позволяют использовать minimally logged (пустая таблица с ключом, индексы строим позже, заливка в порядке кластерного ключа), то даже простой INSERT SELECT отрабатывает так же быстро, как BULK.
Если все-таки желаете сравнивать теплое с мягким, проверяйте (с поправкой на объемы 2008 года)
Using SSIS to load 1TB data into SQL Server in 30 mins, with simplified settings
Давайте сравнивать яблоки с яблоками, а не с теннисными мячиками. В вашем примере можно замерить передачу данных по сети и снова окажется, что она быстрее у РСУБД за счет в разы более компактного табличного формата. Сравнивать время выполнения BULK INSERT корректно не с получением сигнала о передаче пакета (это легко изобразить с SqlBulkCopy.WriteToServerAsync), а с реальной вставкой данных. То, что она не гарантирована - следующий уровень игры.
Если вставлять данные в РСУБД правильным образом, то это не будет медленнее даже не настроенной на durable Монги.
Для слоя БД описана типовая "история успеха":
Возьмем Монгу - это модно, стильно и молодежно
Уррра! Легко загрузили все данные. Но, блин, что-то с запросами совсем беда...
Переходим на Постгрес - это хоть и не молодежно, но модно и, типа, бесплатно
Ура! Запросы, наконец, стало удобно писать, язык человеческий. Но, блин, почему так медленно? Неужели Оракл и Микрософт не зря хотят денег за свои СУБД с оптимизаторами, вылизанными за десятки лет?
Нет, СУБД из Big-3 нам не потянуть, придется перенести часть вычислений из запросов и хранимых процедур в код служб...
Продолжение следует...
Еще индекс с отфильтрацией "левых" значений надо бы упомянуть.
Мне кажется, или в статье действительно не хватает инженерной конкретики? Например, вместо обсуждения производимых пользователем операций, затрат на поддержку (в терминах компонентов, строк кода, связей, сложности, наконец) и интеграцию в вариантах "оставим три среды" и "сделаем одну", тематика сползает на "что отличало её от нас, это эмоциональная привязанность к решению".
Встречный вопрос: "Как использовать вашу библиотеку с custom allocators?"
Обычно аллокатор вставляют в заголовок. Возможно, ваши классы совсем не работают с памятью, ничего не создают и не удалают, тогда, действительно, можно обойтись без него.
Аллокаторы рекомендуются к использованию во всех template-объявлениях, если они представляют собой библиотеку. Никто ведь не знает заранее, когда, кем и с какой целью твой библиотечный код будет использован. По умолчанию просто ставим std::allocator с чувством заботы о ближних.
Быстродействие LibreOffice на "5", это не шутка? Стоит начать редактировать текстовые блоки в презентации на 20 слайдов с задержкой в 2 секунды на отрисовку или рукводство-книгу на 150 страниц...
В тексте не хватает реалистичности, для чего необходимо уточнить технологические ниши таких Вась. Если речь об автоматизации, то Васи должны разбираться в потрохах тиражируемых ERP-систем. Широкое поле для деятельности Вась дают монстры типа SAP, но и 1С тоже сойдет. Выходя за рамки автоматизации, экспертиза СУБД-решений также будет хорошей иллюстрацией, десять тысяч параметров конфигурации Оракла - это вам не масло в мотор залить. Если же речь идет о полностью внутренних вертикальных решениях с тоннами легаси-кода, то Васи тут не помогут.
Принцип garbage in - garbage out никто не отменял. Если вы не можете контролировать чистоту данных при записи в БД, то вам придется делать это потом, при каждом запросе на их извлечение из БД. Это раз. Для подхода "храним все, что прилетает" у вас нет разделения "болота данных" и витрин, это два. 1000 пользователей никогда не работают одновременно над всеми данными, это три.
Иерархические структуры встречается часто, SQL успешно с ними справляется, если правильно подойти к проектированию.
Не только можно, это очень популярная архитектура примерно с середины 1990-х годов - использование процедурного расширения SQL СУБД в качестве сервера приложений с тонким клиентом. Примеры, навскидку, "Босс-компания" (не путать с "Босс-корпорацией") и Ultima-Seller, перетекший в открытый код. Подробнее по ссылке.
Основная проблема того, что называют NoSQL - в непроработанности моделей данных. Зная, что практически все они были известны в дореляционную эпоху (к моменту "великого спора" Кодда с Бахманом их было известно более 40), можно с основанием говорить о неполноте и даже о неполноценности.
Полнота SQL иллюстрируется просто. SQL-запрос над множеством возвращает множество, которое может быть обработано следующим SQL-запросом или подзапросом. В NoSQL даже созданные сверху SQL-подобные языки так не могут, и проблема не в языках, а в модели данных и замкнутости операций. Для выборки, которую не обработать одним запросом, нужно писать программу (здравствуй, Питон). Исключение - KeySQL, где эта теоретическая проблема решена.
Вариант 3, тоже распространенный. Делали проект для заказчика, но по дороге поняли, что можно продать другим с небольшими изменениями. Проект превратился в продукт.
Первый вопрос разработчики задают сами себе: "Мне/нам это нужно?" Найдя рациональные аргументы на этом начальном уровне, можно подступаться к следующему. И начинают обычно с "Нужно ли вообще развивать продукт или можно ограничиться поддержкой?"
Мне не раз приходилось помогать клиентам переносить легаси системы объемом около 1М строк и десятками сторонних компонентов с Д4 и Д7 на 10.х. Дело это небыстрое, но ваше объяснение из разряда "кто не хочет, ищет причины, кто хочет - средства"