forum.opennet.ru - "INTдлиной в 5 байт (mysql)" (19)

форумы

помощь

поиск

регистрация

майллист

ВХОД

слежка

"INTдлиной в 5 байт (mysql)"

Форумы Программирование под UNIX (Public)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[Проследить за развитием треда]

"INTдлиной в 5 байт (mysql)"
Сообщение от alexvs (??) on 13-Дек-06, 14:47
Возможно создать поле с целочисленным типом данных длинной в 5 байт? Необходимо назначить id для 26млрд записей, 4 байт мало, а 8 байт оооочень много. З.Ы.: Как вариант использовать DECIMAL, но боюсь будут большие потери в производительности чем при использовании BIGINT.
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

Оглавление

INTдлиной в 5 байт (mysql), BigHo, 11:20 , 14-Дек-06, (1)

INTдлиной в 5 байт (mysql), mirya, 21:47 , 14-Дек-06, (2)

INTдлиной в 5 байт (mysql), Wulf, 00:55 , 15-Дек-06, (3)
INTдлиной в 5 байт (mysql), kerdan, 22:18 , 15-Дек-06, (4)

INTдлиной в 5 байт (mysql), alexvs, 14:10 , 16-Дек-06, (5)

INTдлиной в 5 байт (mysql), Wulf, 15:14 , 16-Дек-06, (6)
INTдлиной в 5 байт (mysql), BigHo, 11:03 , 18-Дек-06, (7)

INTдлиной в 5 байт (mysql), kerdan, 08:22 , 19-Дек-06, (8)

INTдлиной в 5 байт (mysql), alexvs, 14:26 , 19-Дек-06, (9)

INTдлиной в 5 байт (mysql), BigHo, 14:59 , 19-Дек-06, (10)

INTдлиной в 5 байт (mysql), alexvs, 15:12 , 19-Дек-06, (11)

INTдлиной в 5 байт (mysql), BigHo, 15:55 , 19-Дек-06, (12)

INTдлиной в 5 байт (mysql), alexvs, 16:09 , 19-Дек-06, (13)

INTдлиной в 5 байт (mysql), BigHo, 16:36 , 19-Дек-06, (14)

INTдлиной в 5 байт (mysql), alexvs, 22:01 , 19-Дек-06, (15)

INTдлиной в 5 байт (mysql), AMDmi3, 22:31 , 19-Дек-06, (16)
INTдлиной в 5 байт (mysql), alexvs, 22:48 , 19-Дек-06, (17)
INTдлиной в 5 байт (mysql), AMDmi3, 00:46 , 20-Дек-06, (18)
INTдлиной в 5 байт (mysql), BigHo, 01:02 , 20-Дек-06, (19)

Сообщения по теме [Сортировка по времени, UBB]

1. "INTдлиной в 5 байт (mysql)"

Сообщение от BigHo on 14-Дек-06, 11:20

>Возможно создать поле с целочисленным типом данных длинной в 5 байт?
>Необходимо назначить id для 26млрд записей, 4 байт мало, а 8 байт
>оооочень много.
мне почему то кажется, что заставить MySQL работать с таким объемом данных еще никому не удавалось. Но из-за того, что вопрос был поставлен не в этой плоскости, то могу рекомендовать использовать составной ключ:
id0 INT UNSIGNED NOT NULL,
id1 TINYINT UNSIGNED NOT NULL,
Вместе как раз получается 5 байт. Единственная проблема - нельзя использовать AUTO_INCREMENT на оба поля одновременно.
Другой вариант - использовать для id CHAR(5) BINARY, куда паковать целочисленный идентификатор. Опять же - AUTO_INCREMENT не получится.
Опять же, если таблица используется для нахождения соответствия key -> value, то лучше воспользоваться BerkeleyDB или другим подобным ПО.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "INTдлиной в 5 байт (mysql)"

Сообщение от mirya on 14-Дек-06, 21:47

>>Возможно создать поле с целочисленным типом данных длинной в 5 байт?
>>Необходимо назначить id для 26млрд записей, 4 байт мало, а 8 байт
>>оооочень много.
MEDIUMINT == 6bytes
DECIMAL:
MySQL 5.1 stores DECIMAL and NUMERIC values in binary format. Before MySQL 5.0.3, they were stored as strings. See Chapter 25, Precision Math.
Причем байт выдляется в зависимости от точности

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "INTдлиной в 5 байт (mysql)"

Сообщение от Wulf on 15-Дек-06, 00:55

>Возможно создать поле с целочисленным типом данных длинной в 5 байт?
>Необходимо назначить id для 26млрд записей, 4 байт мало, а 8 байт
>оооочень много.
>
При 26млрд записей в НЕСЕКЦИОНИРОВАННОЙ таблице любой базе будет не очень приятно существовать. Т.к. в Mysql эта самая фича находится еще только в стадии девелопмента, то IMHO лучшим выходом будет сделать псевдосекционирование: те отвести под id-4 байта, но сделать множество таблиц с одинаковой структурой и названием. Причем название таблиц должно отличатся на 1-2 символа и эти символы должны нести в себе информацию о главном ключе поиска. Например строки со словом MYSQL будут лежать в таблице MY_TABLE, а POSTGRE и POSTFIX - в PO_TABLE и т.д. При поиске название таблицы вычисляется из искомого ключа и дальше он продолжается в одной таблице из тучи.
А вообще я-бы поостерегся от хранения большого количества важных данных в этой чудо-программе. Она умеет выкидывать фокусы в неподходящий момент

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "INTдлиной в 5 байт (mysql)"

Сообщение от kerdan on 15-Дек-06, 22:18

>Необходимо назначить id для 26млрд записей, 4 байт мало, а 8 байт
>оооочень много.
Тебе надо переходить на Oracle...
Я читал, что в IBM на ней висят и не такие таблички ;)
И живут уже явно не один год.
Кстати, насчет пяти байт... вспомни асм... если на 32-битной платформе,
то процессору лучше уж 8 байт переваривать, чем 5.
т.к. обычные регистры - 4 байт. (расписывать уж не буду, почему...)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "INTдлиной в 5 байт (mysql)"

Сообщение от alexvs (??) on 16-Дек-06, 14:10

>Тебе надо переходить на Oracle...
>Я читал, что в IBM на ней висят и не такие таблички
>;)
>И живут уже явно не один год.
Таблица будет содержать несколько десятков милиардов записей (10-30млрд), состоять из 9 полей суммарным объёмом 25 байт в основном это вторичные ключи (id). Это проблема для mysql? хотите сказать что не потянет?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "INTдлиной в 5 байт (mysql)"

Сообщение от Wulf on 16-Дек-06, 15:14

>Таблица будет содержать несколько десятков милиардов записей (10-30млрд), состоять из 9 полей
>суммарным объёмом 25 байт в основном это вторичные ключи (id). Это
>проблема для mysql? хотите сказать что не потянет?
Все зависит от того, что Вы с ней собираетесь делать. Для того же оракла максимальный размер секции при которой работу еще можно с натяжкой назвать комфортной - примерно 100 млн. строк. Дальше - кранты. Простые соединения таблиц по primary/foreign key растягиваются на десяток минут. Про конкурентную чтение/запись разговор можно вообще не вести. Кроме мелких выборок по высокоселективным индексам, остальные операции выполняются ооочень долго. Не уверен, что в mysql с этим будет получше. Правда, если вы информацию туда зальете один раз и навсегда и читать будете по primary key, может быть, что-то работоспособное и получится

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "INTдлиной в 5 байт (mysql)"

Сообщение от BigHo on 18-Дек-06, 11:03

>>Тебе надо переходить на Oracle...
>>Я читал, что в IBM на ней висят и не такие таблички
>>;)
>>И живут уже явно не один год.
>Таблица будет содержать несколько десятков милиардов записей (10-30млрд), состоять из 9 полей
>суммарным объёмом 25 байт в основном это вторичные ключи (id). Это
>проблема для mysql? хотите сказать что не потянет?
меня извинят, если я спрошу, а что такое может содержать такое количество записей с таким количеством индексов ? Может исходя из задачи можно предложить лучшее решение (и уж точно не под mysql).
Скажу из чего исхожу. Например, если делать встаку по одной записи (неоптимизированный вариант), то mysql "способен" обработать не более 200 запросов на средней машинке. Даже если допустить, что возможно удасться разогнать систему до 1000 запросов в секунду, то все равно получается, что выполняться запись будет около 10'000'000'000/1'000 секунд, или около ста дней.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "INTдлиной в 5 байт (mysql)"

Сообщение от kerdan on 19-Дек-06, 08:22

Судя по всему тут решили допустить типичную проектную ошибку:
в базу собираются пихать все данные, в которых встречаются не то что повторяющиеся,
но и в принципе пустые записи.
Напишите, хоть, че за задача такая.
P.S. Может вы решили моделировать движение атомов в пространстве 1x1м и записывать
данные в БД? ...шучу, шучу ;)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "INTдлиной в 5 байт (mysql)"

Сообщение от alexvs (??) on 19-Дек-06, 14:26

>Судя по всему тут решили допустить типичную проектную ошибку:
>в базу собираются пихать все данные, в которых встречаются не то что
>повторяющиеся,
>но и в принципе пустые записи.
>
>Напишите, хоть, че за задача такая.
>
>P.S. Может вы решили моделировать движение атомов в пространстве 1x1м и записывать
>
>данные в БД? ...шучу, шучу ;)
Есть сервисы, по типу апача, с нагрузкой 10-15 миллионов клиентов/день. Данные очень схожи с логами апача: ip, что запросил, что получил, тип клиента.... Значения в полях относительно стабильны, поэтому выносятся в отдельные таблицы, а основной будут только сылки на них (ключи). 10 млн *360 = 3.6 млрд ...
Вариант хранения просто в логах отпадает, т.к. данные стаскиваются с нескольких десятков серверов и к ним строятся разнообразнейшие запросы, вплоть до истории отдельного клиента, а ждать пол дня пока грепнется 100Г логов нет возможности.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "INTдлиной в 5 байт (mysql)"

Сообщение от BigHo on 19-Дек-06, 14:59

>Есть сервисы, по типу апача, с нагрузкой 10-15 миллионов клиентов/день. Данные очень
>схожи с логами апача: ip, что запросил, что получил, тип клиента....
>Значения в полях относительно стабильны, поэтому выносятся в отдельные таблицы, а
>основной будут только сылки на них (ключи). 10 млн *360 =
>3.6 млрд ...
>
>Вариант хранения просто в логах отпадает, т.к. данные стаскиваются с нескольких десятков
>серверов и к ним строятся разнообразнейшие запросы, вплоть до истории отдельного
>клиента, а ждать пол дня пока грепнется 100Г логов нет возможности.
Решение - специализированное ПО. Хранение индексов в BerkeleyDB файлах. Только правильно кластеризовать данные. Статичные данные можно хранить в MySQL (если их конечное количество).
Иначе к 100Гб данным добавляется 100Гб индекса, особенно если ключи мелкие. Когда нибудь приходилось восстанавливать рухнувшую БД из-под MySQL ? Думаю после недели восстановления этого рухнувшего индекса невольно подумаешь в сторону grep :) Этот факт можно подтвердить через myisamchk для 10млн. записей в таблице прототипа. Также сомнительно, что после года заполнения этой таблицы MySQL вообще потянет 10 операций вставок в секунду (такое тестирование вообще вряд ли проводилось).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "INTдлиной в 5 байт (mysql)"

Сообщение от alexvs (??) on 19-Дек-06, 15:12

>Решение - специализированное ПО. Хранение индексов в BerkeleyDB файлах. Только правильно кластеризовать
>данные. Статичные данные можно хранить в MySQL (если их конечное количество).
Как раз сейчас отходим от BerkeleyDB, т.к. позволяет хранить только ключ->значение, а как засунуть в в такую базу (даже если в кучу баз связаных ключами) лог апача? и потом делать выборку по типу: колличество уникальных клиентов из такой-то страны, за такой период, с такими параметрами...?
>Иначе к 100Гб данным добавляется 100Гб индекса, особенно если ключи мелкие. Когда
>нибудь приходилось восстанавливать рухнувшую БД из-под MySQL ? Думаю после недели
>восстановления этого рухнувшего индекса невольно подумаешь в сторону grep :) Этот
>факт можно подтвердить через myisamchk для 10млн. записей в таблице прототипа.
>Также сомнительно, что после года заполнения этой таблицы MySQL вообще потянет
>10 операций вставок в секунду (такое тестирование вообще вряд ли проводилось).
Действительно, до тестирования пока не дошёл, сейчас только проэктирую базу.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "INTдлиной в 5 байт (mysql)"

Сообщение от BigHo on 19-Дек-06, 15:55

>>Решение - специализированное ПО. Хранение индексов в BerkeleyDB файлах. Только правильно кластеризовать
>>данные. Статичные данные можно хранить в MySQL (если их конечное количество).
>Как раз сейчас отходим от BerkeleyDB, т.к. позволяет хранить только ключ->значение, а как засунуть в в такую базу (даже если в кучу баз связаных ключами) лог апача? и потом делать выборку по типу: колличество уникальных клиентов из такой-то страны, за такой период, с такими параметрами...?
Вообще в BDB (по моему, начиная с 3.x) есть возможность строить вторичные ключи. Как уникальные, так и с возможностью дубликации. Причем в одном файле с первичным..
Так, для вторичных ключей задается функция, которая из _всей_ записи выделяет фрагменты полей, по которым в конечном итоге будет строиться этот ключ. Вызов этой функции производится внутри самой BDB в виде callback, т.е. имеет свой четко оговоренный интерфейс. Возвращается строка с заявленной длиной. Соответственно, чтобы сохранить число, его сперва надо серилизировать в big-endian формате (network ordering), чтобы оно было отсортированно, как надо.
Программно легче будет работать с кучей мелких фрагментов-таблиц - чинить их, кластеризировать, логически размещать в файловой системе, чем при работе с MySQL. Скорость работы будет примерно одинакова в случае выбора BDB или MYSQL. Можно ожидать отрыв в быстродействии от 2 до 5 раз, если использовать гольный C/C++ к BDB. Если не использовать вторичные ключи, то отрыв будет ближе к 5. Далеко не факт, скорее цифра будет ближе к 4 (я тестировал под Python, разница была в 2 раза, а когда использовал составные ключи, то MySQL обходил в тестах py-bdb, так что все зависит от реализации). Основным ограничением для скорости работы БД является скорость работы дисковой и файловой системы. Конечно при нынешних скоростях процессоров и памяти самым узким местом станет I/O оперции.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "INTдлиной в 5 байт (mysql)"

Сообщение от alexvs (??) on 19-Дек-06, 16:09

>Вообще в BDB (по моему, начиная с 3.x) есть возможность строить вторичные
>ключи. Как уникальные, так и с возможностью дубликации. Причем в одном
>файле с первичным..
Что по этому поводу можно почитать?
Сейчас используется BDB5 под perl'om (p5-BerkeleyDB-0.31). Слышал про небольшие сдвиги в сторону реляционной базы, но никакой документации не удалось найти (может плохо искал).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "INTдлиной в 5 байт (mysql)"

Сообщение от BigHo on 19-Дек-06, 16:36

>Что по этому поводу можно почитать?
>Сейчас используется BDB5 под perl'om (p5-BerkeleyDB-0.31). Слышал про небольшие сдвиги в сторону
>реляционной базы, но никакой документации не удалось найти (может плохо искал).
>
Если программить под perl выигрыша производительности не получится. Может быть интерфейс вторичных ключей забыли в perl API вынести. Если не забыли перенести, то посмотри http://www.sleepycat.com/products/bdb.html, что-то похожее через perldoc надо наити будет.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "INTдлиной в 5 байт (mysql)"

Сообщение от alexvs (??) on 19-Дек-06, 22:01

>Если программить под perl выигрыша производительности не получится. Может быть интерфейс вторичных
>ключей забыли в perl API вынести. Если не забыли перенести, то
>посмотри http://www.sleepycat.com/products/bdb.html, что-то похожее через perldoc надо наити будет.
Там дока только для C,C++,Java.
Допустим взаимосвязь таблиц через ключи я обеспечу собственными силами, а вот как быть с выборкой по одному из десятка полей в одной таблицы? Ведь таблица всё равно остаётся "двухпольной" ключ->значение? как вариант в поле "значение" компресить десяток полей и каждый раз при выборке по одному из них проходить по всем записям в базе, получать "значение" разбивать его на поля и смотреть нужное?
Или я что-то не так понял?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "INTдлиной в 5 байт (mysql)"

Сообщение от AMDmi3 (ok) on 19-Дек-06, 22:31

>Допустим взаимосвязь таблиц через ключи я обеспечу собственными силами, а вот как быть с выборкой по одному из десятка полей в одной таблицы? Ведь таблица всё равно остаётся "двухпольной" ключ->значение? как вариант в поле "значение" компресить десяток полей и каждый раз при выборке по одному из них проходить по всем записям в базе, получать "значение" разбивать его на поля и смотреть нужное?
>Или я что-то не так понял?
BDB поддерживает вторичные индексы. Вот:
http://www.oracle.com/technology/documentation/berkeley-db/db/gsg/C/indexes.html

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "INTдлиной в 5 байт (mysql)"

Сообщение от alexvs (??) on 19-Дек-06, 22:48

>>Допустим взаимосвязь таблиц через ключи я обеспечу собственными силами, а вот как быть с выборкой по одному из десятка полей в одной таблицы? Ведь таблица всё равно остаётся "двухпольной" ключ->значение? как вариант в поле "значение" компресить десяток полей и каждый раз при выборке по одному из них проходить по всем записям в базе, получать "значение" разбивать его на поля и смотреть нужное?
>>Или я что-то не так понял?
>
>BDB поддерживает вторичные индексы. Вот:
>http://www.oracle.com/technology/documentation/berkeley-db/db/gsg/C/indexes.html
Это аналогично join в SQL? Я правильно понял?
Если да, то это меня не сильно интересовало. Сейчас ооочень хотелось б знать как реализовать в BDB следующую таблицу:
ID DATE IP VER ....
пока вижу только следующий вариант:
"ID"->"DATE|IP|VER|...."
ключ->значение

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "INTдлиной в 5 байт (mysql)"

Сообщение от AMDmi3 (ok) on 20-Дек-06, 00:46

>Это аналогично join в SQL? Я правильно понял?
Нет. Некие join cursors там есть, но речь не о них.
Речь о secondary databases - позволяют индексировать базу данных по нескольким полям. Я так понял, тебе именно это нужно.
>Если да, то это меня не сильно интересовало. Сейчас ооочень хотелось б
>знать как реализовать в BDB следующую таблицу:
>ID DATE IP VER ....
>
>пока вижу только следующий вариант:
>"ID"->"DATE|IP|VER|...."
>ключ->значение
Сразу скажу, что в Perl'овом модуле нужной функциональности нет.
А на C/C++ в BDB обычно хранят структуры - там вопрос с разделением полей отпадает сам собой.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "INTдлиной в 5 байт (mysql)"

Сообщение от BigHo on 20-Дек-06, 01:02

>>>Допустим взаимосвязь таблиц через ключи я обеспечу собственными силами, а вот как быть с выборкой по одному из десятка полей в одной таблицы? Ведь таблица всё равно остаётся "двухпольной" ключ->значение? как вариант в поле "значение" компресить десяток полей и каждый раз при выборке по одному из них проходить по всем записям в базе, получать "значение" разбивать его на поля и смотреть нужное?
>>>Или я что-то не так понял?
>>
>>BDB поддерживает вторичные индексы. Вот:
>>http://www.oracle.com/technology/documentation/berkeley-db/db/gsg/C/indexes.html
>Это аналогично join в SQL? Я правильно понял?
неправильно, но ссылка указана на правильную главу. У меня даже есть API под Python, обеспечивающий через py-bdb примитивные функции вставки и выборки таблицы со вторичными ключами с удобным интерфейсом. Правда быстродейственность на большом количестве ключей сильно страдает из-за проблем с быстродействием самого интерпретатора.
>Если да, то это меня не сильно интересовало. Сейчас ооочень хотелось б
>знать как реализовать в BDB следующую таблицу:
>ID DATE IP VER ....
>
>пока вижу только следующий вариант:
>"ID"->"DATE|IP|VER|...."
>ключ->значение
Теперь представь, что associate позволяет тебе привязать callback функцию, которая выбирает IP + DATE из приведеного примера в качестве вторичного ключа. На каждый ключ надо будет делать по одной callback функции. Повторюсь как это работает: при вставке BDB, если зарегестированны вторичные индексы, BDB автоматически для них вызывавет callback функцию, которая принимает всю строку целиком. В нашем случае, это - "DATE|IP|VER|....". Из неё выделяется составная строка, говоря на perl/php наречии:
    return serialize($IP).serialize($DATE);
Получив составленный на основе всей записи составной ключ (не обязательно ключ должен быть составным), происходит прозрачная вставка во вторичный индекс указателя на эту запись. BDB также обеспечивает целостность данных.
В этом смысле BDB представляет большую свободу, чем реляционные таблицы. Так например, я могу составить индекс динамически расчитаным данным, что на SQL логично, но невозможно выразить, как:
CREATE TABLE modular_10 (
  id INT NOT NULL,
  value BLOB NOT NULL,
  PRIMARY KEY (id),
  KEY (MOD(id, 10))
);

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "INTдлиной в 5 байт (mysql)"
Сообщение от BigHo on 14-Дек-06, 11:20
>Возможно создать поле с целочисленным типом данных длинной в 5 байт? >Необходимо назначить id для 26млрд записей, 4 байт мало, а 8 байт >оооочень много. мне почему то кажется, что заставить MySQL работать с таким объемом данных еще никому не удавалось. Но из-за того, что вопрос был поставлен не в этой плоскости, то могу рекомендовать использовать составной ключ: id0 INT UNSIGNED NOT NULL, id1 TINYINT UNSIGNED NOT NULL, Вместе как раз получается 5 байт. Единственная проблема - нельзя использовать AUTO_INCREMENT на оба поля одновременно. Другой вариант - использовать для id CHAR(5) BINARY, куда паковать целочисленный идентификатор. Опять же - AUTO_INCREMENT не получится. Опять же, если таблица используется для нахождения соответствия key -> value, то лучше воспользоваться BerkeleyDB или другим подобным ПО.
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "INTдлиной в 5 байт (mysql)"
	Сообщение от mirya on 14-Дек-06, 21:47
	>>Возможно создать поле с целочисленным типом данных длинной в 5 байт? >>Необходимо назначить id для 26млрд записей, 4 байт мало, а 8 байт >>оооочень много. MEDIUMINT == 6bytes DECIMAL: MySQL 5.1 stores DECIMAL and NUMERIC values in binary format. Before MySQL 5.0.3, they were stored as strings. See Chapter 25, Precision Math. Причем байт выдляется в зависимости от точности
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

3. "INTдлиной в 5 байт (mysql)"
Сообщение от Wulf on 15-Дек-06, 00:55
>Возможно создать поле с целочисленным типом данных длинной в 5 байт? >Необходимо назначить id для 26млрд записей, 4 байт мало, а 8 байт >оооочень много. > При 26млрд записей в НЕСЕКЦИОНИРОВАННОЙ таблице любой базе будет не очень приятно существовать. Т.к. в Mysql эта самая фича находится еще только в стадии девелопмента, то IMHO лучшим выходом будет сделать псевдосекционирование: те отвести под id-4 байта, но сделать множество таблиц с одинаковой структурой и названием. Причем название таблиц должно отличатся на 1-2 символа и эти символы должны нести в себе информацию о главном ключе поиска. Например строки со словом MYSQL будут лежать в таблице MY_TABLE, а POSTGRE и POSTFIX - в PO_TABLE и т.д. При поиске название таблицы вычисляется из искомого ключа и дальше он продолжается в одной таблице из тучи. А вообще я-бы поостерегся от хранения большого количества важных данных в этой чудо-программе. Она умеет выкидывать фокусы в неподходящий момент
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

4. "INTдлиной в 5 байт (mysql)"
Сообщение от kerdan on 15-Дек-06, 22:18
>Необходимо назначить id для 26млрд записей, 4 байт мало, а 8 байт >оооочень много. Тебе надо переходить на Oracle... Я читал, что в IBM на ней висят и не такие таблички ;) И живут уже явно не один год. Кстати, насчет пяти байт... вспомни асм... если на 32-битной платформе, то процессору лучше уж 8 байт переваривать, чем 5. т.к. обычные регистры - 4 байт. (расписывать уж не буду, почему...)
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "INTдлиной в 5 байт (mysql)"
	Сообщение от alexvs (??) on 16-Дек-06, 14:10
	>Тебе надо переходить на Oracle... >Я читал, что в IBM на ней висят и не такие таблички >;) >И живут уже явно не один год. Таблица будет содержать несколько десятков милиардов записей (10-30млрд), состоять из 9 полей суммарным объёмом 25 байт в основном это вторичные ключи (id). Это проблема для mysql? хотите сказать что не потянет?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "INTдлиной в 5 байт (mysql)"
	Сообщение от Wulf on 16-Дек-06, 15:14
	>Таблица будет содержать несколько десятков милиардов записей (10-30млрд), состоять из 9 полей >суммарным объёмом 25 байт в основном это вторичные ключи (id). Это >проблема для mysql? хотите сказать что не потянет? Все зависит от того, что Вы с ней собираетесь делать. Для того же оракла максимальный размер секции при которой работу еще можно с натяжкой назвать комфортной - примерно 100 млн. строк. Дальше - кранты. Простые соединения таблиц по primary/foreign key растягиваются на десяток минут. Про конкурентную чтение/запись разговор можно вообще не вести. Кроме мелких выборок по высокоселективным индексам, остальные операции выполняются ооочень долго. Не уверен, что в mysql с этим будет получше. Правда, если вы информацию туда зальете один раз и навсегда и читать будете по primary key, может быть, что-то работоспособное и получится
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "INTдлиной в 5 байт (mysql)"
	Сообщение от BigHo on 18-Дек-06, 11:03
	>>Тебе надо переходить на Oracle... >>Я читал, что в IBM на ней висят и не такие таблички >>;) >>И живут уже явно не один год. >Таблица будет содержать несколько десятков милиардов записей (10-30млрд), состоять из 9 полей >суммарным объёмом 25 байт в основном это вторичные ключи (id). Это >проблема для mysql? хотите сказать что не потянет? меня извинят, если я спрошу, а что такое может содержать такое количество записей с таким количеством индексов ? Может исходя из задачи можно предложить лучшее решение (и уж точно не под mysql). Скажу из чего исхожу. Например, если делать встаку по одной записи (неоптимизированный вариант), то mysql "способен" обработать не более 200 запросов на средней машинке. Даже если допустить, что возможно удасться разогнать систему до 1000 запросов в секунду, то все равно получается, что выполняться запись будет около 10'000'000'000/1'000 секунд, или около ста дней.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "INTдлиной в 5 байт (mysql)"
	Сообщение от kerdan on 19-Дек-06, 08:22
	Судя по всему тут решили допустить типичную проектную ошибку: в базу собираются пихать все данные, в которых встречаются не то что повторяющиеся, но и в принципе пустые записи. Напишите, хоть, че за задача такая. P.S. Может вы решили моделировать движение атомов в пространстве 1x1м и записывать данные в БД? ...шучу, шучу ;)
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "INTдлиной в 5 байт (mysql)"
	Сообщение от alexvs (??) on 19-Дек-06, 14:26
	>Судя по всему тут решили допустить типичную проектную ошибку: >в базу собираются пихать все данные, в которых встречаются не то что >повторяющиеся, >но и в принципе пустые записи. > >Напишите, хоть, че за задача такая. > >P.S. Может вы решили моделировать движение атомов в пространстве 1x1м и записывать > >данные в БД? ...шучу, шучу ;) Есть сервисы, по типу апача, с нагрузкой 10-15 миллионов клиентов/день. Данные очень схожи с логами апача: ip, что запросил, что получил, тип клиента.... Значения в полях относительно стабильны, поэтому выносятся в отдельные таблицы, а основной будут только сылки на них (ключи). 10 млн *360 = 3.6 млрд ... Вариант хранения просто в логах отпадает, т.к. данные стаскиваются с нескольких десятков серверов и к ним строятся разнообразнейшие запросы, вплоть до истории отдельного клиента, а ждать пол дня пока грепнется 100Г логов нет возможности.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "INTдлиной в 5 байт (mysql)"
	Сообщение от BigHo on 19-Дек-06, 14:59
	>Есть сервисы, по типу апача, с нагрузкой 10-15 миллионов клиентов/день. Данные очень >схожи с логами апача: ip, что запросил, что получил, тип клиента.... >Значения в полях относительно стабильны, поэтому выносятся в отдельные таблицы, а >основной будут только сылки на них (ключи). 10 млн *360 = >3.6 млрд ... > >Вариант хранения просто в логах отпадает, т.к. данные стаскиваются с нескольких десятков >серверов и к ним строятся разнообразнейшие запросы, вплоть до истории отдельного >клиента, а ждать пол дня пока грепнется 100Г логов нет возможности. Решение - специализированное ПО. Хранение индексов в BerkeleyDB файлах. Только правильно кластеризовать данные. Статичные данные можно хранить в MySQL (если их конечное количество). Иначе к 100Гб данным добавляется 100Гб индекса, особенно если ключи мелкие. Когда нибудь приходилось восстанавливать рухнувшую БД из-под MySQL ? Думаю после недели восстановления этого рухнувшего индекса невольно подумаешь в сторону grep :) Этот факт можно подтвердить через myisamchk для 10млн. записей в таблице прототипа. Также сомнительно, что после года заполнения этой таблицы MySQL вообще потянет 10 операций вставок в секунду (такое тестирование вообще вряд ли проводилось).
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "INTдлиной в 5 байт (mysql)"
	Сообщение от alexvs (??) on 19-Дек-06, 15:12
	>Решение - специализированное ПО. Хранение индексов в BerkeleyDB файлах. Только правильно кластеризовать >данные. Статичные данные можно хранить в MySQL (если их конечное количество). Как раз сейчас отходим от BerkeleyDB, т.к. позволяет хранить только ключ->значение, а как засунуть в в такую базу (даже если в кучу баз связаных ключами) лог апача? и потом делать выборку по типу: колличество уникальных клиентов из такой-то страны, за такой период, с такими параметрами...? >Иначе к 100Гб данным добавляется 100Гб индекса, особенно если ключи мелкие. Когда >нибудь приходилось восстанавливать рухнувшую БД из-под MySQL ? Думаю после недели >восстановления этого рухнувшего индекса невольно подумаешь в сторону grep :) Этот >факт можно подтвердить через myisamchk для 10млн. записей в таблице прототипа. >Также сомнительно, что после года заполнения этой таблицы MySQL вообще потянет >10 операций вставок в секунду (такое тестирование вообще вряд ли проводилось). Действительно, до тестирования пока не дошёл, сейчас только проэктирую базу.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "INTдлиной в 5 байт (mysql)"
	Сообщение от BigHo on 19-Дек-06, 15:55
	>>Решение - специализированное ПО. Хранение индексов в BerkeleyDB файлах. Только правильно кластеризовать >>данные. Статичные данные можно хранить в MySQL (если их конечное количество). >Как раз сейчас отходим от BerkeleyDB, т.к. позволяет хранить только ключ->значение, а как засунуть в в такую базу (даже если в кучу баз связаных ключами) лог апача? и потом делать выборку по типу: колличество уникальных клиентов из такой-то страны, за такой период, с такими параметрами...? Вообще в BDB (по моему, начиная с 3.x) есть возможность строить вторичные ключи. Как уникальные, так и с возможностью дубликации. Причем в одном файле с первичным.. Так, для вторичных ключей задается функция, которая из _всей_ записи выделяет фрагменты полей, по которым в конечном итоге будет строиться этот ключ. Вызов этой функции производится внутри самой BDB в виде callback, т.е. имеет свой четко оговоренный интерфейс. Возвращается строка с заявленной длиной. Соответственно, чтобы сохранить число, его сперва надо серилизировать в big-endian формате (network ordering), чтобы оно было отсортированно, как надо. Программно легче будет работать с кучей мелких фрагментов-таблиц - чинить их, кластеризировать, логически размещать в файловой системе, чем при работе с MySQL. Скорость работы будет примерно одинакова в случае выбора BDB или MYSQL. Можно ожидать отрыв в быстродействии от 2 до 5 раз, если использовать гольный C/C++ к BDB. Если не использовать вторичные ключи, то отрыв будет ближе к 5. Далеко не факт, скорее цифра будет ближе к 4 (я тестировал под Python, разница была в 2 раза, а когда использовал составные ключи, то MySQL обходил в тестах py-bdb, так что все зависит от реализации). Основным ограничением для скорости работы БД является скорость работы дисковой и файловой системы. Конечно при нынешних скоростях процессоров и памяти самым узким местом станет I/O оперции.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "INTдлиной в 5 байт (mysql)"
	Сообщение от alexvs (??) on 19-Дек-06, 16:09
	>Вообще в BDB (по моему, начиная с 3.x) есть возможность строить вторичные >ключи. Как уникальные, так и с возможностью дубликации. Причем в одном >файле с первичным.. Что по этому поводу можно почитать? Сейчас используется BDB5 под perl'om (p5-BerkeleyDB-0.31). Слышал про небольшие сдвиги в сторону реляционной базы, но никакой документации не удалось найти (может плохо искал).
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "INTдлиной в 5 байт (mysql)"
	Сообщение от BigHo on 19-Дек-06, 16:36
	>Что по этому поводу можно почитать? >Сейчас используется BDB5 под perl'om (p5-BerkeleyDB-0.31). Слышал про небольшие сдвиги в сторону >реляционной базы, но никакой документации не удалось найти (может плохо искал). > Если программить под perl выигрыша производительности не получится. Может быть интерфейс вторичных ключей забыли в perl API вынести. Если не забыли перенести, то посмотри http://www.sleepycat.com/products/bdb.html, что-то похожее через perldoc надо наити будет.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "INTдлиной в 5 байт (mysql)"
	Сообщение от alexvs (??) on 19-Дек-06, 22:01
	>Если программить под perl выигрыша производительности не получится. Может быть интерфейс вторичных >ключей забыли в perl API вынести. Если не забыли перенести, то >посмотри http://www.sleepycat.com/products/bdb.html, что-то похожее через perldoc надо наити будет. Там дока только для C,C++,Java. Допустим взаимосвязь таблиц через ключи я обеспечу собственными силами, а вот как быть с выборкой по одному из десятка полей в одной таблицы? Ведь таблица всё равно остаётся "двухпольной" ключ->значение? как вариант в поле "значение" компресить десяток полей и каждый раз при выборке по одному из них проходить по всем записям в базе, получать "значение" разбивать его на поля и смотреть нужное? Или я что-то не так понял?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "INTдлиной в 5 байт (mysql)"
	Сообщение от AMDmi3 (ok) on 19-Дек-06, 22:31
	>Допустим взаимосвязь таблиц через ключи я обеспечу собственными силами, а вот как быть с выборкой по одному из десятка полей в одной таблицы? Ведь таблица всё равно остаётся "двухпольной" ключ->значение? как вариант в поле "значение" компресить десяток полей и каждый раз при выборке по одному из них проходить по всем записям в базе, получать "значение" разбивать его на поля и смотреть нужное? >Или я что-то не так понял? BDB поддерживает вторичные индексы. Вот: http://www.oracle.com/technology/documentation/berkeley-db/db/gsg/C/indexes.html
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "INTдлиной в 5 байт (mysql)"
	Сообщение от alexvs (??) on 19-Дек-06, 22:48
	>>Допустим взаимосвязь таблиц через ключи я обеспечу собственными силами, а вот как быть с выборкой по одному из десятка полей в одной таблицы? Ведь таблица всё равно остаётся "двухпольной" ключ->значение? как вариант в поле "значение" компресить десяток полей и каждый раз при выборке по одному из них проходить по всем записям в базе, получать "значение" разбивать его на поля и смотреть нужное? >>Или я что-то не так понял? > >BDB поддерживает вторичные индексы. Вот: >http://www.oracle.com/technology/documentation/berkeley-db/db/gsg/C/indexes.html Это аналогично join в SQL? Я правильно понял? Если да, то это меня не сильно интересовало. Сейчас ооочень хотелось б знать как реализовать в BDB следующую таблицу: ID DATE IP VER .... пока вижу только следующий вариант: "ID"->"DATE\|IP\|VER\|...." ключ->значение
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "INTдлиной в 5 байт (mysql)"
	Сообщение от AMDmi3 (ok) on 20-Дек-06, 00:46
	>Это аналогично join в SQL? Я правильно понял? Нет. Некие join cursors там есть, но речь не о них. Речь о secondary databases - позволяют индексировать базу данных по нескольким полям. Я так понял, тебе именно это нужно. >Если да, то это меня не сильно интересовало. Сейчас ооочень хотелось б >знать как реализовать в BDB следующую таблицу: >ID DATE IP VER .... > >пока вижу только следующий вариант: >"ID"->"DATE\|IP\|VER\|...." >ключ->значение Сразу скажу, что в Perl'овом модуле нужной функциональности нет. А на C/C++ в BDB обычно хранят структуры - там вопрос с разделением полей отпадает сам собой.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "INTдлиной в 5 байт (mysql)"
	Сообщение от BigHo on 20-Дек-06, 01:02
	>>>Допустим взаимосвязь таблиц через ключи я обеспечу собственными силами, а вот как быть с выборкой по одному из десятка полей в одной таблицы? Ведь таблица всё равно остаётся "двухпольной" ключ->значение? как вариант в поле "значение" компресить десяток полей и каждый раз при выборке по одному из них проходить по всем записям в базе, получать "значение" разбивать его на поля и смотреть нужное? >>>Или я что-то не так понял? >> >>BDB поддерживает вторичные индексы. Вот: >>http://www.oracle.com/technology/documentation/berkeley-db/db/gsg/C/indexes.html >Это аналогично join в SQL? Я правильно понял? неправильно, но ссылка указана на правильную главу. У меня даже есть API под Python, обеспечивающий через py-bdb примитивные функции вставки и выборки таблицы со вторичными ключами с удобным интерфейсом. Правда быстродейственность на большом количестве ключей сильно страдает из-за проблем с быстродействием самого интерпретатора. >Если да, то это меня не сильно интересовало. Сейчас ооочень хотелось б >знать как реализовать в BDB следующую таблицу: >ID DATE IP VER .... > >пока вижу только следующий вариант: >"ID"->"DATE\|IP\|VER\|...." >ключ->значение Теперь представь, что associate позволяет тебе привязать callback функцию, которая выбирает IP + DATE из приведеного примера в качестве вторичного ключа. На каждый ключ надо будет делать по одной callback функции. Повторюсь как это работает: при вставке BDB, если зарегестированны вторичные индексы, BDB автоматически для них вызывавет callback функцию, которая принимает всю строку целиком. В нашем случае, это - "DATE\|IP\|VER\|....". Из неё выделяется составная строка, говоря на perl/php наречии: return serialize($IP).serialize($DATE); Получив составленный на основе всей записи составной ключ (не обязательно ключ должен быть составным), происходит прозрачная вставка во вторичный индекс указателя на эту запись. BDB также обеспечивает целостность данных. В этом смысле BDB представляет большую свободу, чем реляционные таблицы. Так например, я могу составить индекс динамически расчитаным данным, что на SQL логично, но невозможно выразить, как: CREATE TABLE modular_10 ( id INT NOT NULL, value BLOB NOT NULL, PRIMARY KEY (id), KEY (MOD(id, 10)) ); P.S. Подобным образом устроена работа и в mysql. Принцип работы всех реляционных баз данных один и тот же. Что для и тебя видится реляционной таблицей, по сути является множеством таблиц - (ключ, единственное значение). Правда за счет того, что в виде значения используется указатель на запись, на основании которой расчитано значение ключа, накладные расходы на хранение избыточной информации не сильно завышены. P.P.S. Специально написал много, а также сбивался и повторялся :)
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

Архив \| Удалить	Индекс форумов \| Темы \| Пред. тема \| След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 \| 2 \| 3 \| 4 \| 5 ] [Рекомендовать для помещения в FAQ]