Ответы пользователя по тегу Базы данных
  • Как мировая практика подсказывает проверять на уникальность при вставке строк в таблицу БД?

    terrier
    @terrier
    может какие то подводные камни

    Ну, есть конечно.
    Допустим вы проверяете из приложения, есть ли табельный номер в таблице. Находите, что нет и пытаетесь следующим запросом вставить строчку. Но между запросами такая строчка уже появилась и вам все равно надо обрабатывать исключение.
    Поддержание консистентности данных - задача базы, никаких велосипедов тут изобретать не надо.
    Ответ написан
    Комментировать
  • MySql/SqLite/MongoDB кто меньше всех потребляет оперативной памяти?

    terrier
    @terrier
    К чему конкретно этот вопрос? Все эти базы займут не больше памяти, чем вы укажете в настройках. Если же вам интересно, кто эффективнее использует память - это надо конкретно сравнивать форматы хранения данных и индексов (B-tree, BSON, LSM-tree и т.д.) и их реализации. Плюс учитывайте сжатие/не сжатие данных.
    1) Правильно ли чем больше mysql база тем больше потребление памяти потому что база загружается в память?

    Нет, память используется для кэширования и сама по себе база в память в общем случае не подгружается.
    2) И верно ли что sqlite в отличии от mysql базу в оперативной памяти не хранит,

    Как мы установили, и mysql базу в оперативной памяти тоже не хранит. Логика подсказывает, что в sqlite должен экономнее относиться к ресурсам, но это догадки.
    3) Что насчет MongoDB?

    Да, что там у монги? Там BSON для данных и тот же B-tree для индексов ( в основном ). В тех, бенчмарках, которые я видел b-tree индекс в монге занимал на треть больше места, чем в mysql. Но вы померяйте и выложите актуальные данные, очень интересно.
    Ответ написан
    Комментировать
  • На сколько необходимы внешние ключи в базах данных?

    terrier
    @terrier
    1. Всегда ли необходимы внешние ключи?

    Внешние ключи необходимы несколько менее, чем всегда.

    2. Чем чревато отсутствие внешних ключей?

    Потерей консистентности данных

    3. Какие могут быть причины для отсутствия внешних ключей в этой базе?

    Производительность и локи. Вот здесь отвечал на похожий вопрос в контексте постгреса, у других RDBMS примерно так же.
    Ответ написан
    Комментировать
  • Как перевести БД MySQL на БД PostgreSQL?

    terrier
    @terrier
    Существуют ли какие-нибудь средства/утилиты, с помощью которых можно перевести всю структуру и все данные БД MySQL на БД PostgreSQL?

    Безусловно
    Ответ написан
    Комментировать
  • Что значит современные технологии БД?

    terrier
    @terrier
    Судя по всему, вам задали реферат в колледже или каком-то плохом институте. В этом случае не надо париться, а надо скопипастить произвольный кусок документации отсюда и это уже будет на достаточно хорошем уровне.
    Ответ написан
    Комментировать
  • Как правильно разгрузить таблицу статистики для такого проекта?

    terrier
    @terrier
    Да, партиционирование по времени здесь вполне подходит. Разницы между партиционированием и отдельными таблицами в вашем случае особо нет, но с партиционированием, скорее всего окажется меньше мороки.
    Статистику и аналитику лучше читать с отдельной реплики, не с той, на которую идет активная запись.
    В 5.7 есть релевантные для вас улучшения, но на самом деле после минимальной настройки все вполне себе взлетит.
    P.S.
    не менее 150 тысяч записей в сутки.

    Почти 2 записи в секунду. Можно хоть на айфоне базу гонять :)
    Ответ написан
  • Всегда ли нужно использовать внешние ключи?

    terrier
    @terrier
    Есть ли выигрыш в производительности, если использовать внешние ключи в postgresql?

    Видимо имелось в виду, есть ли выигрыш в производительности если НЕ использовать внешние ключи. Да, может быть. Во-первых сама по себе проверка foreign key не бесплатна - это system-level триггер. Во-вторых в постгресе берется ( среди прочего ) SHARED лок на строку в родительской таблице. Соответсвенно - нужно учитывать влияние этого на производительность и следить за дедлоками.

    Однако вот вам практический совет - оставьте пока эти ключи, постгрес весьма быстр даже с ними и очень большой вопрос стоит ли жертвовать целостностью данных ради некоторого ( возможно несущественного ) прироста производительности ( а без ключей данные у вас гарантированно разъедутся).
    Ответ написан
    4 комментария
  • Как верно проектировать базу данных?

    terrier
    @terrier
    Пугаться "большого" количества таблиц не стоит, особенно если "большое" - это десятки.
    Если вам некомфортно работать с таким числом таблиц , настройте свои инструменты ( или возьмите нормальные, если текущие не тащат )
    Ответ написан
    Комментировать
  • Какую БД выбрать для проекта с более чем 3 миллионами insert/update в час?

    terrier
    @terrier
    Ну, тут, есть несколько моментов
    - Сама по себе скорость 1k инсертов в секунду не является запредельной ни для какого хранилища на нормальном железе.
    Ну вот, например, постгрес.
    - Вопрос: что вы с этими данными потом делаете?
    Судя по десяти индексам вы одновременно из этой же таблицы активно читаете и это, наверное, не совсем разумно.
    Если у вас куча инсертов приходят всплесками, то проще сначала вставить данные в таблицу без индексов ( prepared statements, по X строк в стейтменте, Y стейтментов в транзакции, где X и Y надо твикать в зависимости от железа ), а потом уже построить индексы. Если возможно, может быть вообще сделать "COPY ... BINARY " вместо инсертов.

    Можно также копировать в UNLOGGED таблицу без индексов, а потом либо сделать ее LOGGED, либо спокойненько скопировать уже в нормальные таблицы из которых уже читать.

    >> Потом она падает в ноль

    Чекпоинт видимо пришел. Его можно отложить в настройках
    Ответ написан
    3 комментария