Форум Пользователи Пыхослёт
новые сообщения ответы на мои сообщения избранное скрытые темы случайный топик ёбнуть всё в новых вкладках

Форум → Разработка → Базы данных → Mysql и PK

Mysql и PK

  • vasa_c

    Сообщения: 3131 Репутация: N Группа: в ухо

    Spritz Янв. 8, 2016, 9:38 п.п.

    Кто знает ответ на следующий идиотский вопрос?

    Есть таблица в мускле, там некие сущности, у каждого из них есть всякие типы, подтипы (строковые) и айдишники какие-то. Плюс некое число. Пример записи:

    type | subtype | 12345 | anothertype | 23456 | 27

    Можно, в принципе, типы при обращении сокращать:

    t | s | 12345 | a | 23456 | 27

    Нужное значение только последнее - 27, все остальные поля, по сути, первичный ключ. По отдельности они никак не используются.

    Все запросы только к одному полю и по первичному ключу. Типа set("t:s:12345a23456", 27) или get("тоже самое").

    Собственно вопрос, есть ли разница в эффективности, держать этот PK расхуяченным по разным колонкам или можно не парится и всё соеденить в строку тип "t:s:12345a23456" и её первичным ключом назначить?

    Спустя 61 сек.

    Осподи, пиздец, даже аська столько говна в текст не пихала...

    Спустя 151 сек.

    :h::u::y::p::i::z::d:a:d::j::i::g::u::r::d:a

  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz Янв. 8, 2016, 9:45 п.п., спустя 6 минут 58 секунд

    думаю строка выиграет, так как тот же композитный первичный ключ в мускуле внутрях всеж таки это btree наверное, лучше просто хеш таблица из строк должна быть. но строчные данные больше места занимают да, возможно есть смысл по какой то формуле построить big int число из этих колоночных данных и сделать его первичкой. ну и все зависит от того ради скольки собственно строчек такие старания :)

    Спустя 33 сек.

    зы: когда говорил что выиграет строка я имел ввиду что одинарный первичный лучше композитного

    Сапожник без сапог

  • vasa_c

    Сообщения: 3131 Репутация: N Группа: в ухо

    Spritz Янв. 8, 2016, 10:01 п.п., спустя 16 минут 48 секунд

    @phpdude, а то, что ключ это строка, а не число, это никак не роляет? То есть строка фиксированной длины в те же 4 байта, что и INT, никак не хуже?

    И такой момент, этих типов/подтипов фиксированное число, штук 20. Можно сделать просто 20 таблиц одинаковых для каждого варианта? PK тогда сузится. Количество таблиц не усугубит ситуацию?

    Записей порядка 10М.

  • artoodetoo

    Сообщения: 5147 Репутация: N Группа: в ухо

    Spritz Янв. 8, 2016, 11:30 п.п., спустя 1 час 28 минут 10 секунд

    Хуярь в строку. Если они правда имеют смысл только вместе, это не нарушит ничью девственность.

    Ага, сделай 20 таблиц. Чисто чтобы поржать. Потом будешь клеить их юнионами и джойнами в каждом запросе :)

    ιιlllιlllι унц-унц

  • vasa_c

    Сообщения: 3131 Репутация: N Группа: в ухо

    Spritz Янв. 8, 2016, 11:32 п.п., спустя 1 минуту 55 секунд

    @artoodetoo, повторюсь:

    Все запросы только к одному полю и по первичному ключу. Типа set("t:s:12345a23456", 27) или get("тоже самое").

  • artoodetoo

    Сообщения: 5147 Репутация: N Группа: в ухо

    Spritz Янв. 9, 2016, 12:06 д.п., спустя 34 минуты 31 секунду

    А зачем повторяешь, всё давно решено! )

    Спустя 132 сек.

    Какой-то редиской пахнет, помоему. Реляционность отдыхает.

    ιιlllιlllι унц-унц

  • kostyl

    Сообщения: 5210 Репутация: N Группа: Джедаи

    Spritz Янв. 9, 2016, 2:27 д.п., спустя 2 часа 21 минуту 5 секунд

    я бы сделал два поля - один бы этой строкой, как уникальный ключь, даже может как дуд говорит интовый чтобы индексация быстрая была, а второй - первичный, гененил был его, потому что такие ключи бывают превращаются не в уникальные

  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz Янв. 9, 2016, 3:20 д.п., спустя 53 минуты 9 секунд

    я бы поступил еще проще - закешировал бы нахуй все в память и не ебал себе мозг.

    Спустя 10 сек.

    при 10М строк то

    Сапожник без сапог

  • artoodetoo

    Сообщения: 5147 Репутация: N Группа: в ухо

    Spritz Янв. 9, 2016, 10:17 д.п., спустя 6 часов 56 минут 43 секунды

    дудоправда. производительность решать кешированием, в кеше использовать склеенную строку или хеш. а логическое построение из N колонок можно оставить как есть, мало ли что завтра понадобится.

    упринципе, можно совместить решения: колонки не считать ключем, а сделать новое поле под синтетический PK из склеенных обрезков.

    Спустя 120 сек.

    :h:u:j:p:i:z:d:a: lol васяц, у меня не получается так.

    Спустя 141 сек.

    "t:s:12345a23456"

    Спустя 13 сек.

    5a2

    Спустя 11 сек.

    a

    Спустя 38 сек.

    :p:i:z:da

    Спустя 42 сек.

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

    ιιlllιlllι унц-унц

  • vasa_c

    Сообщения: 3131 Репутация: N Группа: в ухо

    Spritz Янв. 9, 2016, 12:58 п.п., спустя 2 часа 40 минут 41 секунду

    Редисы-хуередисы хороши, когда оперативки девать некуда, а на средней виртуалке толку от них мало. Тем более данных много, а требуется каждое конкретное редко.

    В общем, 25 таблиц жрут втрое меньше места и индексы в них на порядок меньше, минусов пока не нашёл )

  • master

    Сообщения: 3244 Репутация: N Группа: Джедаи

    Spritz Янв. 9, 2016, 3:09 п.п., спустя 2 часа 10 минут 57 секунд

    a

    Спустя 16 сек.

    b

    Спустя 37 сек.

    :h: :u: :i: :p: :i: :z: :d: a

    Спустя 21 сек.

    хм

    Спустя 70 сек.

    :c:

    не всё полезно, что в swap полезло

  • artoodetoo

    Сообщения: 5147 Репутация: N Группа: в ухо

    Spritz Янв. 9, 2016, 5:12 п.п., спустя 1 час 6 минут 9 секунд

    Место на диске дёшево. Удобство использования - вот что имеет значение.

    ιιlllιlllι унц-унц

Пожалуйста, авторизуйтесь, чтобы написать комментарий!

наше все Форум Пользователи Пыхослёт Slack Тикеты
социализация
(ц) пыха.ру / с 2007 года         Total: 0.009s         Часовой пояс — Europe/Moscow
ХУЙ