2anonymous (*) (28.09.2005 12:20:25) >Если база больше 100 метров будут исключительно глюки и гемор. >А уж как она любит повредить собственный файл базы данных... ммм...

Отвечать за базар надо, трепать языком о своих кривых руках - стиль анонимусов. В моей базе на данный момент 45 таблиц по 3-4Гб. Летает, порчи данных нет, ни разу не пришлось восстанавливаться из бэкапа. Пусть постгрес и оракл отдохнут.

А кто как бэкапит mysql'ные базы? У меня база на ~2 гига бэкапится минут 10, и соот-но все таблицы лочатся :(

> дык простой %like% отрабатывает больше минуты на 4.1.11

A B-tree index can be used for column comparisons in expressions that use the =, >, >=, <, <=, or BETWEEN operators. The index also can be used for LIKE comparisons if the argument to LIKE is a constant string that does not start with a wildcard character.

http://dev.mysql.com/doc/mysql/en/mysql-indexes.html

юзай FULLTEXT

>>Если бы я мог предугадать, когда запрос сработает, а когда - нет, тогда бы запостил. Им же примеры нужны. Всё, что я могу сказать - это "иногда не работает". Не один я это говорил и ранее.

А сдавая продукт заказчику мы будем говорить, что мол это мускуль. Он таблицы роняет - это нормально. А руки у нас прямые. И вообще это моно в автомате фиксить. Кстати, кто может похвастаться что у него на постгри таблица ни стого ни с сего слетела? Нет таких?

ЗЫ Брошу ка и я свой кирпичик в шустрый мускуль.

> У меня база на ~2 гига бэкапится минут 10, и соот-но все таблицы лочатся :(
--single-transaction ?

> А сдавая продукт заказчику мы будем говорить, что мол это мускуль. Он таблицы роняет - это нормально. А руки у нас прямые. И вообще это моно в автомате фиксить.

Я не говорил, что для какого-то заказчика делаю проект.

> Кстати, кто может похвастаться что у него на постгри таблица ни стого ни с сего слетела?

В postgresql есть таблицы типа myisam? :) Я говорил только о них. В транзакционных таблицах mysql такой ошибки нет.

> В postgresql есть таблицы типа myisam? :)
fsync ему отключи будет нечто похожее по скороси и падучести :)))

>_очень_ много времени должно пройти (3-5 лет). слишком долго mysql позиционировал себя, как дешевую говнобазу для бедных

Очень нехорошо так говорить. (но от этого автора ничего иного и не услышишь). / по скорости работы и надёжности MySQl рвёт эти большие (и реально мало кому нужные базы)

Кому нужны это большие базы ? от силы 1-2 процентам (вот они пусть и покупают их с саппортом)/ для 99.9 процентов задач ни транзакции ни хранимые процедуры не нужны

Хм-м-м... Юзаю MySQL не так много, но чтобы ПАДАЛО - никогда. Запросы - да, кое-что из MS SQL переставало работать под MySQL. Лечилось переписыванием, но зато работало шустро. А что касается "у меня всё медленно" - так в этом не обязательно виноват мускуль - СКОРЕЕ ВСЕГО кривоватые, неоптимизированные запросы. По-хорошему, большинство геморойных ситуаций можно решить временными таблицами.

Падают базы MySQL . падают . но ничего страшного . это - нормально (бэкап то на что и журнал запросов)

> А что касается "у меня всё медленно" - так в этом не обязательно виноват мускуль - СКОРЕЕ ВСЕГО кривоватые, неоптимизированные запросы.

последний яркий пример

mysql> select count(*) from sw_9999t_hst_h_c_bugreport;
+----------+
| count(*) |
+----------+
| 31456 |
+----------+
1 row in set (26.20 sec)

4.1.13-max, dual xeon 3ggz

что тут оптимизировать? :)
(на втором прогоне работает быстро. но кого это волнует?)

не верю (count(*) вообще мгновенно отрабатывается)

Каунт - что тут оптимизировать? :)

Я вам не верю. Как можно так загнать мускуль? У меня дуал ксеон, 30 баз данных под мускулом, весом под 8 Гб, из них пять отбирают большую часть места. На моих задачах все быстро работает, включая лайки, про каунты я вобще молчу.

ну лайки то только при индексации быстро (а это жутко увеличивает размер базы). а вот такие каунты - это MySQL реально мгновенно делает. там по другому алгоритм выборки делается если count(*) надо

Железо такое же. Версия такая же. Первый прогон.

mysql> select count(*) from data;
+-----------+
| count(*)  |
+-----------+
| 195800987 |
+-----------+
1 row in set (0.00 sec)

> не верю (count(*) вообще мгновенно отрабатывается)

попробуй на innodb. Там делается table scan by design. Вот такие они новаторы.

> Железо такое же. Версия такая же. Первый прогон.

innodb?

MyISAM

Когда блоб безразмерный будет?

>Когда блоб безразмерный будет?

глюки ловить невылавливаемые?

dump snapshot-а fs. ;)

Mysql конечно хорошо, но вот была одна задача,необходимо было хранить весь IP Трафик, то есть -- попакетно, для чего, вопрос другой к теме не относящийся. За месяц набегало до 10 млн строк + плюс несколько таблиц с полльзователями и так далее. Mysql не падал, работал стабильно, но запросы с объединениемя (нескольками) отрабатывал очень долго, причем затыкался на селектах, -- 10-15 минут. Индексы не помогали. ПРишлось переползти на POstgres -- база такая же, строк там уже около 30 млн, я про ту табличку говорю, где ip хранится, но вот view, запросы, всё отрабатывает максимум за 30-40 секунд -- разница заметна? Я не скажу что mysql сосёт, вовсе нет, но каждому своё. Где-то Mysql -- лучшее решение, а где-то -- ему ой как далеко от совершенства. Хорошо, что хоть view появились, очень не хватало, но переползать обратно не собираюсь.

И innodb и myisam:

mysql> select count(*) from bell.pin; +----------+ | count(*) | +----------+ | 792579 | +----------+ 1 row in set (0.00 sec)

mysql> select count(*) from fin.invoice; +----------+ | count(*) | +----------+ | 783924 | +----------+ 1 row in set (0.00 sec)

mysql> select count(*) from fin.invoice_data; +----------+ | count(*) | +----------+ | 795577 | +----------+ 1 row in set (0.00 sec)

mysql> select count(*) from bell.pin_txn; +----------+ | count(*) | +----------+ | 2984207 | +----------+ 1 row in set (0.00 sec)

> по скорости работы и надёжности MySQl рвёт эти большие

На каких задачах рвет по скорости, мы знаем -- мелкие простые выборки без серьезной конкуренции. А вот про надежность -- это ты зря.

> реально мало кому нужные базы

Да-да. ;) LOL.

> для 99.9 процентов задач ни транзакции ни хранимые процедуры не нужны

Для этих задач sqlite или какая-нибудь bdb подходит не в пример лучше.

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

>> У меня база на ~2 гига бэкапится минут 10, и соот-но все таблицы лочатся :(
>--single-transaction ?
На MyISAM ? :)

> MyISAM

Для получения результата count(*) на MyISAM не требуется обход строк, а на InnoDB - требуется.

> последний яркий пример

А сервер винтом не шуршит? :)

>Если база больше 100 метров будут исключительно глюки и гемор.

У меня несколько _таблиц_ по гигабайту :) Глюков и геморра нет. Что я не так делаю? :)

А Postgre научился хранить разные таблицы в разных кодировках, включая UTF-8? А то это в своё время было той фигнёй, из-за которой он сразу выпал из рассмотрения.

Хех - развеселили 8))

Для всех "знатоков" BDB... Прежде чем о ней что-либо говорить, посмотрите хотя бы тот куцый и неполный sample API (20% где-то возможностей освещено), что с ней идет. Как только задача выходит за рамки стандартной возни с табличками - мимо нее не проедешь. (ничего другого попросту нет)

Так что выражение "какая-то BDB" в терминологии LOR - это "вызывающе неверная информация" 8)

> А Postgre научился хранить разные таблицы в разных кодировках

А ты можешь рассказать, зачем в пределах одной базы иметь таблички в разной кодировке? А за одно объяснить, зачем такое усложнение collation?

>На каких задачах рвет по скорости, мы знаем -- мелкие простые выборки без серьезной конкуренции. А вот про надежность -- это ты зря.

baka угу - вот для хостинга и под веб MySQL - идеально/ про надежность я не совсем не прав / просто MySQL выдержит больше запросов чем закрытые коммерческие базы данных (реляционные) / если много запросов то другие базы просто не будут выдерживать такой нагрузки как MySQL / вот я о чём / о том что могут портиться isam/myisam это известно

> вот для хостинга и под веб MySQL - идеально

Для _небольшого_ хостинга и под _маленький_ веб. ;)

> просто MySQL выдержит больше запросов

Бенчмарки множества конкурентных запросов в студию.

> чем закрытые коммерческие базы данных (реляционные)

А ты сравни. Ну с открытыми тоже, с Postgres, например.

> если много запросов то другие базы просто не будут выдерживать такой нагрузки как MySQL ... о том что могут портиться isam/myisam это известно

"Другие базы" легко смогут выдержать превосходящую нагрузку, при этом isam/myisam рассыпаться не будут. ;)

тем не менее для хостингов нет реальной альтернативы MySQL / Postgres она только функционально мощнее - спору нет / не на маленьких хостингах а вообще почти на всех стоит MySQL / это неописуемо сколько там баз на 1 сервер приходится и сколько запросов обрабатывается (и сколько одновременный соединений она держит) / черт с ними с сыпящимися базами - они восстанавливаются легко / зато быстро

иногда надёжность это просто чтобы сервер выдержал нагрузку и не пришлось его в неподходящее время приводить в себя / не всегда это замечательно - медленная непортящаяся база (чаты/форумы/гостевые/новости не особо критично там если десяток записей потерялось при падении (порчи) базы myisam)

>>> У меня база на ~2 гига бэкапится минут 10, и соот-но все таблицы лочатся :(
>>--single-transaction ?
>На MyISAM ? :)
а чем InnoDB не устраивает ?

> тем не менее для хостингов нет реальной альтернативы MySQL

Сколько угодно. В подавляющем большинстве случаев sqlite или bdb будет более оптимальным выбором.

> не на маленьких хостингах а вообще почти на всех стоит MySQL

Ну так если "пых-пых кодеры" ничего не умеют, кроме как методом тыка писать всю логику вперемежку с html. А любой нормальный разработчик запихает логику в базу, оставив на веб-сервер только темплейты. И получит на порядок меньше запросов, не говоря уже обо всем остальном.

> это неописуемо сколько там баз на 1 сервер приходится и сколько запросов обрабатывается (и сколько одновременный соединений она держит)

То есть оценить не в состоянии. Зато МНОГО! "А куча -- это сколько?" ;)

> черт с ними с сыпящимися базами - они восстанавливаются легко

LOL.

> Если база больше 100 метров будут исключительно глюки и гемор.

Знаешь такой сервер wikipedia.org? Входит в 50 самых популярных сайтов инета (по трафику). Баз данных не один десяток гигов и всё это работает под обычным MySQL (ну apache со squid, конечно). См. http://meta.wikimedia.org/wiki/Wikimedia_servers

> > для 99.9 процентов задач ни транзакции ни хранимые процедуры не нужны

> Для этих задач sqlite или какая-нибудь bdb подходит не в пример лучше.

http://bash.org.ru/quote.php?num=512

> Знаешь такой сервер wikipedia.org?
Это тот у которого недавно база накрылась медным тазом? Ню-ню :)

>fsync ему отключи будет нечто похожее по скороси и падучести

он и с отключенным fsync-ом нормально работает

> А любой нормальный разработчик запихает логику в базу

И получит по шее. =)

> Это тот у которого недавно база накрылась медным тазом? Ню-ню :) На моей памяти база ещё ни разу не накрывалась, обычно проблемы с memcache и squid

Аче, клевый слоган - Программирование на Базах Данных ; ) Увольте всех своих программистов, наймите ДБА )

А потом ишо и гуй бум в БД ложить, а че? ) пусть она гуй рисует )

У википедии были проблемы с мускулом, если грубо - свет вырубило у них в серверной, сервера остановились и куча табличек попортилась при этом. Но они очень быстро все восстановили.

>>fsync ему отключи будет нечто похожее по скороси и падучести
> он и с отключенным fsync-ом нормально работает
в зависимости от WAL трафика, хотя если в железе уверен и шнурок от упса есть может оно того и стоит, но я лучше buffered WAL writes дождусь

>> А любой нормальный разработчик запихает логику в базу

>И получит по шее. =)

И получит по шее, если запихнет в базу не всю логику, а только ее часть.

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

господа где вы такую траву курити.

То кто-то придумал какой-то VACUM в MySQL 5.0

То MVCC нет - не называется это MVCC но тем не менее Innodb основан на подобных принципах - более дого более продвинут чем PostgreSQL с автоматическим пурджингом и большим набором режимов изоляций

>более дого более продвинут чем PostgreSQL с автоматическим пурджингом и большим набором режимов изоляций

Осталось только заствить все это добро работать; примерно полгода девелопмента. А потом - еще подождать полгода-год, пока выловят все баги. Итого: к лету 2007 года MySQL будет примерно такого же уровня, что PostgreSQL 7.2.... Всего-то через несколько лет после.

А ставить RC(x) или только что зарелизенную версию на продакшн сервер... ну, понятно, да?