Ответы пользователя по тегу MySQL
  • Каков алгоритм импорта CSV в БД?

    @andrshpa
    LOAD DATA INFILE '/status2_50m.csv'
    INTO TABLE compression_test.accounts_status50m
    FIELDS TERMINATED BY ';' ESCAPED BY '\\'
    LINES STARTING BY '' TERMINATED BY '\n'
    IGNORE 1 LINES
    (@col1,@col2,@col3) set account_id=@col1,service_id=@col2,status=@col3;


    Думаю вполне понятный пример, в Вашей ситуации поможет добавление этой команды
    (@col1,@col2,@col3) set account_id=@col1,service_id=@col2,status=@col3;
    Ответ написан
    Комментировать
  • MariaDB(mySQL) - как быстро(!) оставить только уникальные варианты?

    @andrshpa Автор вопроса
    Помогло использование вместо DISTINCT

    GROUP_BY + индекс на столбец по которому он выполняется.

    Exploding - персональное спасибо!
    Ответ написан
    Комментировать
  • Огромная БД mySQL- что изучить?

    @andrshpa Автор вопроса
    Посматриваю в строну noSQL, в частности - Хранилища колонок, а именно Apache Cassandra.
    Но совсем не уверен что это будет правильным выбором.
    Смущает отсутствие возможности делать привычные выборки, и так же то, что данная СУБД рассчитана больше на постоянное добавление в неё данных чем на работу с существующими.
    Я несколько в замешательстве. С одной стороны, в некоторых аспекта noSQL очень привлекателен. Но как делать на нем подобные выборки //Фильтр может быть вроде: выбрать все аккаунты с +(1) на определенных сервисах(при этом на сервисы есть доп фильтр - по hard-level и domain), + еще к этому всему надо будет прикрутить фильтр по датам, упустил из виду, но в целом сути это не меняет.
    я слабо представляю. Как в принципе делать их на реляционных базах данных - понятнее.

    Более подробное описание задачи(дубль из моего коммента выше):
    "БД содержит в себе таблицы
    accounts - в ней "столбцы" - ID(автоинкремент), email(varchar 255), password(varchar 255), login(varchar 255), и comment (TEXT). Для comment понимаю что нужно выносить в отдельную таблицу т.к. их будет
    немного на общем фоне и это повысит производительность.
    services - ID(автоинкремент), name (varchar 255), hard_level(tinyint), domain (varchar 255)
    status - ID(автоинкремент), account_id(int 11), service_id(int 11), value(tinyint)

    Как это все работает думаю понятно:
    В таблицу accounts вносятся аккаунты.
    В таблице services практически не меняются сервисы.
    В таблице status при появлении информации вносится связка account_id - соответствующий ID аккаунта из acccounts, service_id - соответствующий ID сервиса, и значение 0/1. Для одного аккаунта может быть кол-во записей от нескольких, до полного кол-ва сервисов(160+)

    Сейчас в базе есть 18млн тестовых записей в accounts, на основании которых я попробовал заполнить status. там начали получаться огромные значения ID, все лагает*. На реальном количестве аккаунтов 250млн+ - значения ID в таблице status станут просто огромными - грубо говоря что в районе 42500000000 - 12-значное число, что мне кажется соооовсем не здорово.

    Так же для получения результата будет использоваться JOIN при такой архитектуре таблицы, что тоже плохо для производительности.

    Фильтр может быть вроде: выбрать все аккаунты с +(1) на определенных сервисах(при этом на сервисы есть доп фильтр - по hard-level и domain), + еще к этому всему надо будет прикрутить фильтр по датам, упустил из виду, но в целом сути это не меняет.

    *комп i7 3770, 8gb RAM, win7, установлен отдельно Apache и mySQL(не настраивал особо пока). сервер есть примерно такой же мощности, можно ставить любую ОС и делать что угодно. "
    "
    Ответ написан