Рекомендованные сообщения

Байт, а что лучше использовать вместо innodb ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Лучше для чего?

Каждый тип в той или иной степени подходит для определённых задач.

Для многих задач и innodb'а за глаза хватит — зависит от.

Изменено пользователем Байт

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В основном несколько десятков колонок INT и FLOAT, ну и еще несколько текстовых по 1000 байт. И всего около 30 тыщ записей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

innodb'а за глаза.

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

 

Одна таблица что ли? :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Байт, нет конечно, с десяток таблиц, при запросе они скрепляются по id и т.п. Запросы оптимизированы, колонки нужные проиндексированы. Апдейтами не пахнет и не будет :rulez: Просто интересно, раньше я на innodb сидел потому как по умолчанию стоял такой тип))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да уж, Байт, спасибо за информацию:rolleyes:

Все никак руки до доков не доходят, может летом все это дело почитаю про БД)

 

Зы у меня максимум 16 тыс записей в таблице было, так что скорость держится на преемлимом уровне)

Изменено пользователем RPG

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что лучше?

Каталог фильмов, нужно реализовать возможность добавления нескольких жанров к ожному фильму

вариант один - держать текстовое поле, к котором через пробел писать id жанра, который есть у этого фильма (1 3 12 15) а затем делать select * from table where genre like '%ид_жанра%'

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

 

Вопрос - что из этого оптимальнее по скорости? или может есть еще какие обходные пути?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2 вариант лучше.

В первом случае у тебя не будет использоваться индекс.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Байт, собсно так и сделал, попробуем)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 вариант лучше.

В первом случае у тебя не будет использоваться индекс.

Ну а если по полю genre индекс соорудить? Да не простой а full text search? Тогда надо еще посмотреть кто кого. Хотя, если честно, это сильно попахивает извращениями.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Ну а если по полю genre индекс соорудить? Да не простой а full text search?

Че, правда, индекс по строковому полю будет быстрее, чем по интам?

Вы, батенька, мне глаза открываете на MySQL.

А если еще представить какие проблемы с изменением / удалением и добавлением индексов, а так же с поиском фильмов сразу по двум категориям ( не говоря уж о трех и более), то становится понятно, что в данном случае подобное предложение идет далеко и быстро.

 

Это общие рассуждения про организацию структуры с текстовыми индексами

 

Ну а если говорить конкретно про LIKE и "%текст%", то повторю — Like в этом случае не будет юзать индекс. Курите мануал.

Изменено пользователем Байт

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Байт, у мну еще пара вопросов, уже лень копать эти мануалы...

можно ли в запросе like поставить вместо % (ноль символом и более) другую заглушку (ноль или один символ) как в регулярных выражениях?

REGEXP не юзаю, показался слишком медленным

 

и еще - насколько я понял, фуллтекст он хоть и с подсчетом релевантности, но не может искать похожие слова (то есть там нельзы поставить этот процент). Какая замена проценту (и существует ли) в этом случае? Впрочем, не факт что это быстрее лайка будет работаь...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вообще говоря, за использование like надо бить по рукам. Поэтому я и не скажу RPG про заглушку '_' которая заменяет один символ. А за одно упоминание regexp надо вообще расстреливать на месте без суда и следствия. Фуллтекст или любое другое условие будет работать гораздо быстрее вышеупомянутых косячных операторов.

 

И дело тут не в индексах. Уважаемый Байт, не надо зацикливаться на индексах. Во многих случаях индексы сильно вредят производительности. И дело не в сравнении текстовых и интегер индексов, дело в сравнении алгоритмов. Сколько индексов используется при классическом связывании многие ко многим? 2. А в фуллтекст используется 1. Естественно, фуллтекст индекс тоже не одним куском хранится. В итоге выходит примерно одинаково. Всё зависит от кривости реализации фуллтекст в MySQL. Но опять же повторю, что использование фуллтекста в этом случае сильное извращение.

Поделиться сообщением


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

Пример можно?

Правильно построенный индекс повредить не может.

Его отсутствие — более чем.

 

Сколько индексов используется при классическом связывании многие ко многим? 2. А в фуллтекст используется 1

Пример запроса в студию. Ибо либо Вы не досчитали индекс при фултексте, либо построили кривой при интах. Пример запроса дайте.

 

В итоге выходит примерно одинаково.

Это не так.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Байт, прогоню тесты на своей базе (нужно оптимизировать для поиска в 15 мб базе, но фактически по названию фильма и актерам + дата выпуска).

В ощем фуллтекст индекс можно юзать, если мне кто-нибудь скажет, какой заменитель у фуллтекста символу %

like '%blahblahblah%'

а там как?

 

Usama Bin Laden, меня лайк устраивает

оказывает записи 0 - 29 (6,765 всего, Запрос занял 0.0011 сек)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати что за беда не пойму, создал движок который заносит список файлов в базу (там и латиница и русский язык). Но поиск иногда глючит, если задать поиск %ххх% (русские х) то почему то выдает некоторые названия где такого сочетания букв даже нету. В чем трабла (предполагаю конечно что кодировка, таблица в latin1, данные полученные после scandir сразу отправлялись на запись в базу)?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Пример можно?

Правильно построенный индекс повредить не может.

Его отсутствие — более чем.

Enter password:

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL> create table test (id integer not null, name varchar2(255));

Table created.

SQL> create unique index ix_test on test(id);

Index created.

SQL> insert into test (id, name) (select rownum,object_name from all_objects);

50161 rows created.

SQL> commit;

Commit complete.

SQL> exec dbms_stats.gather_table_stats(user,'TEST');

PL/SQL procedure successfully completed.

SQL> commit;

Commit complete.

SQL> explain plan for select * from test where id>0;

Explained.

SQL> @?/RDBMS/ADMIN/UTLXPLS

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 1357081020
--------------------------------------------------------------------------
| Id  | Operation		 | Name | Rows  | Bytes | Cost (%CPU)| Time	 |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |	  | 50161 |  1371K|	56   (2)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| TEST | 50161 |  1371K|	56   (2)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------

  1 - filter("ID">0)

13 rows selected.

SQL> explain plan for select /*+index(test ix_test)*/ * from test where id>0;

Explained.

SQL> @?/RDBMS/ADMIN/UTLXPLS

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 609311751
---------------------------------------------------------------------------------------
| Id  | Operation				   | Name	| Rows  | Bytes | Cost (%CPU)| Time	 |
--------------------------------------------------------------------------------------

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT			|		 | 50161 |  1371K|   330   (1)| 00:00:04 |
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST	| 50161 |  1371K|   330   (1)| 00:00:04 |
|*  2 |   INDEX RANGE SCAN		  | IX_TEST | 50161 |	   |	95   (2)| 00:00:02 |
---------------------------------------------------------------------------------------
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------

  2 - access("ID">0)

14 rows selected.

SQL>

То есть если заставить Oracle использовать правильный индекс (а кто может сказать что он неправильный?) то запрос тормознет в 5 раз. Запрос сравнения фуллтекст индекса и интегер приводить не буду, так как во-первых у меня нет MySQL (а в Oracle FTS работает иначе, к тому же там есть Index Organized Tables), во-вторых мне не очень интересно колупаться с таким извратом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

касательно MySQL могу сказать, что там индексы просто реактивные :blink: правда он иногда забывает их юзать - за этим надо следить...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Dark-Demon, щас погоняю тесты, посмотрим)))

 

Итак, приступлю к тестированию поиска. Слишком огромную базу решил не делать, добавление индексов потом превратится в проблему:rofl:

Что было сделано: написал бота, который должен заполнить базу. В качестве базы слов используется роман Шолохова "Тихий Дон", слов там предостаточно. Роман был разбит на слова, затем случайным образом из них формировалась таблица (не будем о тонкостях)

id int unsigned autoincrement

name char(255) - одно слово (сначала без индексов)

text (type text) - там около 100 слов, тут заюзан фуллтекст индекс

записей: 212996

объем базы: 109 310 КБ

 

тест 1: выборка по id - не скажу что тормозит, но могло быть и получше:

SELECT * FROM `test` WHERE id =205086

1 всего, Запрос занял 0.0264 сек

SELECT * FROM `test` WHERE id =150

1 всего, Запрос занял 0.0158 сек

 

тест 2 - точное совпадение имени - ничего хорошего (не забываем, индекс не создан)

SELECT * FROM `test` WHERE name='мама'

1 всего, Запрос занял 0.3574 сек

тест 3 - сравнение лайком

SELECT * FROM `test` WHERE name like 'мама%'

27 всего, Запрос занял 0.3309 сек

работает даже чуть быстрее чем просто равенство

SELECT * FROM `test` WHERE name like '%папа%'

52 всего, Запрос занял 0.2261 сек

наверное количество результатов влияет на скорость:rofl:

 

Итог - несмотря на полное отсутствие индексов, лайк неплохо справляется со своей работой

 

кстати,

SELECT * FROM `test` WHERE name regexp 'папа'

52 всего, Запрос занял 0.3593 сек

зря его так ругали

 

тест 4 - тут нас ожидает сюрприз: я уже упоминал, что на поле текст создан фуллтекст индекс. Смотрим:

SELECT * FROM `test` WHERE text like '%папа%'

5,103 всего, Запрос занял 0.0048 сек

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

НО

SELECT * FROM `test` WHERE text like '%абракадабра%'

MySQL вернула пустой результат (т.е. ноль рядов). (Запрос занял 0.3955 сек)

вот так...

 

тест 5: используем свой движок поисковой системы мускула. В целом результат гораздо лучше лайковского, учитывая, что полей найдено много меньше, чем при лайке. Кстати, может это глюк моего сервера, но AGAINST ('*папа*') и AGAINST ('папа') выдают совершенно идентичные результаты! То есть были найдены все слова, где есть "папа" (не папаня или еще что-то в этом духе)

SELECT * FROM `test` WHERE MATCH (text) AGAINST ('*папа*');

496 всего, Запрос занял 0.0013 сек

Когда-то я читал что лайк работает быстрее фуллтекста, но в новых версиях это не так (у меня 5-й мускул)

 

Сейчас машина парится с созданием индекса для колонки имя, посмотрим, изменит ли это что-нибудь, и в какую сторону.

 

Все, готово, поехали дальше

тест 6 (с индексом для поля имя)

SELECT * FROM `test` WHERE name='мама'

1 всего, Запрос занял 0.0540 сек

было 0.3 с чем-то. ну неплохо)

SELECT * FROM `test` WHERE name like 'мама%'

27 всего, Запрос занял 0.2447 сек - слабый прирост, и с таким временем выборки опасно жить

SELECT * FROM `test` WHERE name like '%папа%'

52 всего, Запрос занял 0.2284 сек - то же самое...

 

 

создаем на поле name фултекст индекс, вот результат:

SELECT * FROM `test` WHERE name like '%папа%'

52 всего, Запрос занял 0.2346 сек

SELECT * FROM `test` WHERE MATCH (name) AGAINST ('*папа*');

3 всего, Запрос занял 0.0004 сек

 

вот такая история

 

объясните плиз, почему звездочка не пашет?:blink:

 

Выводы: фултест индекс работает на удивление быстро, но он добавил базе лишних 150 метров веса. Но мне кажется, он стоит того

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

насколько я понял звёздочка может быть только в конце и только в логическом режиме. http://dev.mysql.com/doc/refman/5.0/en/fulltext-boolean.html

 

 

Выводы: фултест индекс работает на удивление быстро, но он добавил базе лишних 150 метров веса. Но мне кажется, он стоит того
более чем в два раза? многовасто будет...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
более чем в два раза? многовасто будет...

меньше чем в полтора раза базу увеличил, но все равно неприятно

 

Кстати из-за кеша в мускуле, результаты приведены с его использованием (то есть первые вызовы такого же запроса была намного больше, для лайки это почти 4 сек)

 

Все-таки я думаю нужно юзать фултекст там, где идет выборка по тексту, ваше мнение?

Изменено пользователем RPG

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
То есть если заставить Oracle использовать правильный индекс (а кто может сказать что он неправильный?) то запрос тормознет в 5 раз.

То, что индекс тормознет я вам мог сказать и без оптимизатора Оракла.

Неужели не понимаете, что при таких условиях фулскан по-любому будет быстрее, чем чтение сначала файла индекса, а потом чтение файла данных? Делать из этого выводы, что индексы чуть ли не зло — неблагодарное дело-то.

 

Вы сравните, к примеру, запросы

select /*+index(test ix_test) */ * from test where id>1000 and id<2000

и

select /*+no_index(test ix_test) */ * from test where id>1000 and id<2000

 

вы и в этом случае будете утверждать, что фулскан лучше, а индекс — зло? А если записей несколько сотен миллионов?

Изменено пользователем Байт

Поделиться сообщением


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

в это режиме не рассчитывается релевантность, что за черт?<_<

 

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

 

Байт, Вы сравните, к примеру, запросы

select /*+index(test ix_test) */ * from test where id>1000 and id<2000

и

select /*+no_index(test ix_test) */ * from test where id>1000 and id<2000

 

не нашел разницы (одинаково по 0.0011 сек)

Изменено пользователем RPG

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

hah.gif

 

а ее на мускуле и не будет.

В запросе-то указываются хинты для оракла %)

Для мускула это будут просто комментарии, которые он проигнорирует.

А оракл вполне себе их будет использовать и поведет себя по-разному

 

*рыдает под столом от смеха*

Изменено пользователем Байт

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
А если записей несколько сотен миллионов?
гигантомания? ^_^

 

в это режиме не рассчитывается релевантность, что за черт?
гм... чувствую тебе стоит освоить сей инструмент: translate.ru ^_^

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
гм... чувствую тебе стоит освоить сей инструмент: translate.ru smile.gif

где свзяь?

 

гигантомания? smile.gif

не это просто банковские базы данных уже пошли в ход:horse:

 

Создал базу с кейвордами, сама она вышла небольшая (3 мб) а вот база для связи каждого кейворда и записи - 200 мб

 

Скорость немного больше чем у фуллтекст

корое бредовая была затея:russian:

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL> create table test (id integer not null, name varchar2(255));

Table created.

SQL> create unique index ix_test on test(id);

Index created.

SQL> insert into test (id,name) values (1,'sdfsdfsdfsdfsd');

1 row created.

SQL> insert into test (id,name) values (2,'sgfsdfffggf');

1 row created.

SQL> commit;

Commit complete.

SQL> exec dbms_stats.gather_table_stats(user, 'TEST');

PL/SQL procedure successfully completed.

SQL> commit;

Commit complete.

SQL> set autotrace on;
SQL> select * from test where id>0;

	ID NAME
------------------------------------------------------------------------------------------
	 1 sdfsdfsdfsdfsd
	 2 sgfsdfffggf

Execution Plan
----------------------------------------------------------
Plan hash value: 609311751
---------------------------------------------------------------------------------------
| Id  | Operation				   | Name	| Rows  | Bytes | Cost (%CPU)| Time	 |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT			|		 |	 2 |	32 |	 2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST	|	 2 |	32 |	 2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN		  | IX_TEST |	 2 |	   |	 1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

  2 - access("ID">0)

Statistics
----------------------------------------------------------
	  1  recursive calls
	  0  db block gets
	  4  consistent gets
	  0  physical reads
	  0  redo size
	434  bytes sent via SQL*Net to client
	334  bytes received via SQL*Net from client
	  2  SQL*Net roundtrips to/from client
	  0  sorts (memory)
	  0  sorts (disk)
	  2  rows processed

SQL> select /*+full(test)*/ * from test where id>0;

	ID NAME
------------------------------------------------------------------------------------------
	 1 sdfsdfsdfsdfsd
	 2 sgfsdfffggf

Execution Plan
----------------------------------------------------------
Plan hash value: 1357081020
--------------------------------------------------------------------------
| Id  | Operation		 | Name | Rows  | Bytes | Cost (%CPU)| Time	 |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |	  |	 2 |	32 |	 3   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| TEST |	 2 |	32 |	 3   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

  1 - filter("ID">0)

Statistics
----------------------------------------------------------
	  1  recursive calls
	  0  db block gets
	  8  consistent gets
	  0  physical reads
	  0  redo size
	434  bytes sent via SQL*Net to client
	334  bytes received via SQL*Net from client
	  2  SQL*Net roundtrips to/from client
	  0  sorts (memory)
	  0  sorts (disk)
	  2  rows processed

SQL> 

А при малом количестве записей индекс быстрее! Дорогой Байт! Вы не первый день работаете с СУБД и знаете всё о чем я тут толкую как свои пять пальцев. Но нахрена говорить новичкам что использование индекса всегда хорошо!? Вот начитаются люди Ваших сообшений, а потом я вижу проекты в которых на каждое поле в таблице построен такой такой хитрый индекс, что даже оптимизатор оракла путается. Я уж не говорю про жалобы что Oracle, MySQL, MSSQL, PostgreSQL, FireBird (нужное подчеркнуть) говно, так как инсерты там сильно тормозят. Аккуратнее. На Вас смотрят тысячи и внимают Вашим словам, иногда, к сожалению, буквально.

Поделиться сообщением


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

если напихать индексов на каждое поле, то инсерты естественно будут тормозить^_^

 

теоретически индексты ставятся там, где нужно искать какие-то поля, причем в профессионально написанных скриптах делают так:

id с автоинкрементом - primary

другие числовые поля - index

текстовые поля - fulltext

 

И все будет хорошо хоть с маленькими хоть с большими базами)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

гигантомания? :blink:

Да нет, относительно маленькая база по меркам больших проектов.

Просто один и тот же запрос на маленькой таблице может работать совсем не так, как на большой.

Но до поры до времени. А потом начнутся танцы с бубном — у нас иногда несколько дней уходит на оптимизацию одного запроса. Один и тот же запрос можно переписать несколькими способами и у каждого будет свой план выполнения, своя скорость, свои ресурсы итп. И из этого всего надо выбрать оптимальный, который не поставит проект раком в случае непредвиденных обстоятельств. В общем, достаточно интересное занятие :lol:

 

нахрена говорить новичкам что использование индекса всегда хорошо!?

Хорошо, переформулирую:

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

 

Так лучше?

 

На Вас смотрят тысячи и внимают Вашим словам, иногда, к сожалению, буквально.

Вы льстите форуму Корбины :o

 

 

причем в профессионально написанных скриптах делают так

Открою секрет — индексы бывают составными и примари может быть на несколько полей, если это необходимо для конкретной задачи :-p

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас