Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
ScareCrow Текущие реляционные СУБД создавались 30 лет назад (а кто и больше) тот же мускул не старее 15 лет. откуда такие цифры? просто для красного словца? есть много свежих решений ориентированных имеено на веб и на различные специфические задачи. все зависит от того что нужно в каждом конкретном случае. ScareCrow чего хочется от СУБД из коробки Максимально эффективное кэширование, в идеале IN MEMORY БД, которая для сохранности пишет на диск. Кластеризуемость из коробки. Можно даже слабо связаную пример sql.ru - каждый форум своя железяка, но все это не должно трогать приложение. То есть приложению пофигу сколько там у СУБД серверов. Работа со структурами средней сложности. Оптимизатор 100 табличного джойна не нужен, но и key=>value хранилище это не то. Простое администрирование. Нормальный интерфейс - желательно SQL. все это есть в большинстве современных СУБД гдето больше гдето меньше. серьезные решения стоят денег - искать бесплатный аналог оракла - глупо. если тормозят ваши 10 запросов то надо и заниматься их оптимизацией а не искать сразу же "Супер СУБД" котора я все может закешировать, работает быстрее, сам горизонтально расширяется заражая собой другие серверы ..... если бы такая тут все бы уже о ней знали. ps в мире тысячи высоконагруженных проектов крутятся на томже мускуле и ничего. постгресс мало в чем отстает. надо учиться правильно готовить а не искать серебрянную пулю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2010, 22:46 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
ScareCrowвсе просто. MySQL. я сейчас смотрю на то как 10 запросов по 0.05 секунд отжирают полсекунды формирования страницы. при том что у меня на 8 гиг оперативки 1.5 гига базы вместе с индексами и 20 процессов Апача. Нее, это 10 запросов и как минимум 10+10=20 межпроцессных взаимодействий вокруг них отжирают полсекунды Или не 20, а 110 или 1010 --- в зависимости от того, сколько результатов возвращается клиенту и как именно. Хотите действительно быстрой работы --- выбирайте СУБД с поддержкой HTTP, а не LAMP, разбирайтесь с чем-то вроде vhost_define и радуйтесь производительности, но вот цена разработки при этом очень серьёзно подрастёт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2010, 22:55 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
Как насчет того чтобы перенести в Сравнение СУБД? Я понимаю что тема с разрезом на веб и если конкретнее то именно в применении к ПХП, но все же? Мне кажется там более дельные ответы будут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2010, 22:58 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
r uв мире тысячи высоконагруженных проектов крутятся на томже мускуле и ничего. постгресс мало в чем отстает. надо учиться правильно готовить а не искать серебрянную пулю. Кстати да, это в первую очередь. Для начинающих и даже для крепких середнячков мускуля/постгреса вполне хватает, а дешевизна студентов компенсирует все неизбежные мелкие грабли. Ворчалки по поводу плохой масштабируемости того же мускуля надо понимать правильно --- при размерах активного подмножества данных в десятки миллионов строк и десяти и более клиентах на процессорное ядро он действительно начинает потихоньку проигрывать некоторым "бегемотистым" системам. При этом на маленьких объёмах он "по умолчанию" обыгрывает бегемотиков и в полтора и в два раза, и серьёзно побить его удаётся только объединением клиента и сервера в одном процессе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2010, 23:09 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
Для ворочающих носом от MySQL и иже с ним (типа слишком простые и т.п.) есть одна немецкая конторка, которая пишет БД так называемую Real-Time DB KDB+ Вот там из коробки и масштабируемость и кластеризация и in-memory и работа в реалтайме с огромными объемами данных :) вот только стоит она $40.000 per CPU при минимальной лицензии 4 CPU Если вам для веба нужна такая ДБ то почему бы и нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 13:28 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
anvanoДля ворочающих носом от MySQL и иже с ним (типа слишком простые и т.п.) есть одна немецкая конторка, которая пишет БД так называемую Real-Time DB KDB+ Уже американская, переехали они :) И если не секрет, то для какого именно покупателя они назвали вам такие цены? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 13:50 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
ScareCrowВиртуозо дешевле. У Kx традиционно хорошие наработки по анализу серий, вся эта математика встроена прям в базу и не требует никаких дополнительных денег. Это для некоторых специальных приложений большой плюс. С другой стороны, Virtuoso цепляется к любым "посторонним" источникам данных, поэтому хороша как средство интеграции. В итоге имеем два совершенно разных и не конкурирующих друг с другом продукта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 14:27 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
а нам татарам. с нашими десятью запросами на страницу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 14:32 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
нам бы эта.. бд целиком в оперативку бы... без tmpfs и прочего... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 14:33 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
ScareCrowнам бы эта.. бд целиком в оперативку бы... без tmpfs и прочего... Сконфигурируйте память под дисковые буферы размером больше, чем вся БД --- и всё. Останется только проблема производительности после холодного старта, но её большинство СУБД либо позволяют решить административными методами, либо существенно "смягчают" массовым чтением вместо единичных страниц, пока есть пустая буферная память. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 14:37 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
это проходит под категорией "прочего". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 14:46 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
ScareCrowнам бы эта.. бд целиком в оперативку бы... без tmpfs и прочего... Нуу, тут можно подойти и с аппаратной стороны :) Вот такую фиговину впихуете (одну или несколько) и располагаете на ней любую обычную ДБ. Она как бы и не in memory, а с другой стороны in-memory по производительности :) на специфических именно для OLTP систем случайных дисковых чтениях производительность возрастает на порядок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 15:19 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
моя плакает. а нет СУБД которая изначально без костылей всё в памяти держит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 15:23 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
ScareCrowмоя плакает. а нет СУБД которая изначально без костылей всё в памяти держит? Что значит "без костылей"? Мне кажется сомнительным существование DB, которая чисто "in-memory" без твердой копии данных где бы то ни было. В чем её смысл? А модули, отвечающие за поднятие в память отдельных частей DB по-моему есть в каждой серъезной СУБД. Например, у более близкого мне Оракла - это TimesTen. И почему эти механизмы вдруг стали "костылями"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 15:31 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
ScareCrowмоя плакает. а нет СУБД которая изначально без костылей всё в памяти держит? То есть с полным чтением всего дискового барахла прям в момент старта? Вот уж не рекомендую для веба, потому что при агрессивных юзерах время полного простоя при сбое должно быть минимальным. Шлёпает себе юзер по страничкам, вдруг бац --- сервер упал. ЧП --- " Ч его-то П оломалось". Но юзеру ещё невдомёк. Он кликает ещё раз. И ещё. А вдруг поможет? С каждой секундой простоя число энергично кликающих юзеров будет расти, пока не пойдёт осознание и разочарование. Если вы будете долго читать весь диск, то когда вы радостно откроете подры для работы сразу на полной скорости, у вас стресс может получиться куда серьёзней, чем если б вы на меньшей скорости хотя бы начали окучивать хотя бы часть запросов. При тормозном но всё же старте юзер увидит видит хоть как-то ползущий "градусник", и у него хватит ума больше не кликать. Вот если клиенты --- роботы по расписанию, то там да, "возможны варианты", надо аккуратно считать и выбирать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 15:33 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
авторТо есть с полным чтением всего дискового барахла прям в момент старта не смешите мои тапочки. прочитать мои полтора гигабайта в память - это сколько секунд? авторИ почему эти механизмы вдруг стали "костылями"? потому что (идем по второму разу) авторТекущие реляционные СУБД создавались исходя из следующих предположений: 1) Памяти гораздо меньше чем данных 2) Работа с оперативными данными 3) Работа со сложной структурой 4) Работа на одной большой железяке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 15:39 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
ScareCrowне смешите мои тапочки. прочитать мои полтора гигабайта в память - это сколько секунд? Так все разговоры про кластер --- ради всего лишь 1.5Gb? Не 1500, не 150, даже не 15? Улыбнуло до ушей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 15:47 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
ScareCrowмоя плакает. а нет СУБД которая изначально без костылей всё в памяти держит? Не, мсье определенно знает толк... Значит сконфигурировать инишку mysql-я - это богохульство, надо чтобы СУБД сама догадалась, сколько можно себе выделить памяти для чего? Не совсем понятная логика. Голова у вас на плечах или у шуруповерта, которым вы шурупы вкручиваете? )))) Вам то лучше знать, сколько из 4 гиг можно отдать для СУБД, сколько PHP, сколько Апачу, сколько жрут те, кто не настраивается. Отдайте ей гига два памяти и будет вам постепенно счастие, когда все используемые данные в память перелезут (или пол счастья, если пол беды там на самом деле в самих запросах кроется). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 16:01 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
авторТекущие реляционные СУБД создавались исходя из следующих предположений: 1) Памяти гораздо меньше чем данных 2) Работа с оперативными данными 3) Работа со сложной структурой 4) Работа на одной большой железяке.[/quot] Если верить документации и разработчикам, вышеупомянутый мной TimesTen изначально разрабатывался не как копия обычной базы в памяти, а именно как in-memory база расчитанная на работу именно с большими объемами оперативной памяти (превышающими объемы собственно данных), а не как обычно "памяти меньше чем данных". Тут нет такого понятия как "блоки данных", "буферный кеш" и т.п. даже индексы по таблицам содержат просто указатели на память, где лежат данные. Вытащить строку по индексу тут = просто разименовать указатель. Правда изначально не было поддержки кластеризации. Недавно сделали полноценную поддержку кластеров (с год назад), но у меня пока не было прикладных задач, на которых можно было бы эти новые фичи потестить. Даже по пункту №3 изначально она проектировалась как упрощенная БД, без полноценной поддержики даже родного ораклового PL/SQL. То есть нельзя сказать, что она изначально затачивалась под работу с какими-то сложными структарами данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 16:07 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
ScareCrow, Собственно вот http://dev.mysql.com/doc/refman/5.6/en/innodb-buffer-pool.html The larger the buffer pool, the more InnoDB acts like an in-memory database, reading data from disk once and then accessing the data from memory during subsequent reads. The buffer pool even caches data changed by insert and update operations, so that disk writes can be grouped together for better performance. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 16:13 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
да, Оракл моя любимая СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 16:13 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
Edd.DragonScareCrow, Собственно вот http://dev.mysql.com/doc/refman/5.6/en/innodb-buffer-pool.html The larger the buffer pool, the more InnoDB acts like an in-memory database, reading data from disk once and then accessing the data from memory during subsequent reads. The buffer pool even caches data changed by insert and update operations, so that disk writes can be grouped together for better performance. ага, плавали. все прелести из списка плюс еще и версионность? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 16:18 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
авторЗначит сконфигурировать инишку mysql-я - это богохульство, надо чтобы СУБД сама догадалась, сколько можно себе выделить памяти для чего? когда я говорю что хочу in memory BD - это значит что я хочу in memory BD которая как ей и положенно ВСЁ держит в памяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 16:27 |
|
||
|
СУБД для веб.
|
|||
|---|---|---|---|
|
#18+
anvano, А накладные расходы на мьютексы у TimesTen волшебным образом испарились? Это весьма полезная при определённых обстоятельствах тулза, но никак не волшебная палочка. Напр., сжатое вертикальное храненение квалификационной базы TPC D scale 1 в RDF-представлении требует примерно 6 байт на факт, хранение того же факта в виде 4-х 64-битных указателей потребует 32 байт. То есть на этом приложении TimesTen выиграет в производительности ценой пятикратного роста объёма требуемой памяти. При объёмах побольше scale 1 рост цены оборудования на таких задачах становится "неприличным" --- cравните-ка цену материнки с 64 гигами ОЗУхи и материнки с с 320 гигами :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 16:29 |
|
||
|
|
start [/forum/topic.php?fid=23&startmsg=36844473&tid=1463313]: |
0ms |
get settings: |
6ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
32ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 242ms |
| total: | 365ms |
| 0 / 0 |
