1.1, Ян Злобин (ok), 14:26, 26/09/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Бедняги. Сколько ж костылей они придумали, чтобы MySQL мог работать в их масштабах.
| |
|
2.2, Аноним (-), 17:48, 26/09/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Бедняги. Сколько ж костылей они придумали, чтобы MySQL мог работать в
> их масштабах.
Этот костыль никак не привязанк к мускулу. Вообще.
| |
2.3, KO (?), 17:49, 26/09/2011 [^] [^^] [^^^] [ответить]
| +/– |
В их масштабах все может работать только с костылями.
ВАШ КО
| |
|
|
2.5, Crazy Alex (??), 23:40, 26/09/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если имеете в виду FreeBSD - то конторе размеров фейсбука наваять свой (довольно небольшой) велосипед к хорошо поддерживаемой и распространённой системе гораздо логичнее, чем возиться с довольно экзотической ОС, на которую портирована довольно-таки монструозная ФС из другой экзотической ОС. Монструозность и экзотичность почти автоматом означают большое количество ошибок. Солярис в плане надёжности (используется довольно слабо, но есть возможность получить качественную поддержку), но вариант на линуксе явно дешевле.
| |
|
3.6, iZEN (ok), 00:07, 27/09/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Если имеете в виду FreeBSD - то конторе размеров фейсбука наваять свой (довольно небольшой) велосипед к хорошо поддерживаемой и распространённой системе гораздо логичнее, чем возиться с довольно экзотической ОС
FreeBSD довольно распространённая ОС из всех Unix-подобных. Так что поддержка и сопровождение не составят огромного труда по сравнению, скажем, с теми же AIX, HP-UX или Solaris.
>, на которую портирована довольно-таки монструозная ФС из другой экзотической ОС.
ZFS не монструознее XFS (по объёму кода), отлажена и документирована весьма качественно.
> Монструозность и экзотичность почти автоматом означают большое количество ошибок.
Если система не писалась с расчётом на обеспечение отказоустойчивости и живучести, то даже критические ошибки в ней — обычное дело. Во главу угла при разработке ZFS ставилась надёжность и непротиворечивость.
> Солярис в плане надёжности (используется довольно слабо, но есть возможность получить качественную поддержку), но вариант на линуксе явно дешевле.
Вариант на традиционных ФС линукса не обеспечивает той надёжности и живучести, что обеспечивается в ZFS изначально. Нету в линуксе сквозной целостности данных, как ни прикручивай костыли.
| |
|
4.9, Crazy Alex (ok), 15:08, 27/09/2011 [^] [^^] [^^^] [ответить]
| +/– |
У фри распространённость несколько не та, что у соляриса или чпукса - по ним есть серьёзные курсы, сертификация и т.п. И для них доступна поддержка от производителя - не знаю, как оракловская, о о сановской я плохого не слышал. У линукса кое-что из поддержки тоже есть, плюс в силу распространённости гораздо меньше шанс нарваться на экзотические грабли, которых никто не знает.
Что до объёма кода - сходу данных не нашел, а самому считать неохота. Но из общих соображений - сомнительно, учитывая, что zfs включает в себя кучу функционала, которого в XFS той же нет.
А критерий "обеспечения отказоустойчивости и живучести" - практика и только практика. И практики использования у более традиционных XFS, Ext3 (да, пожалуй, уже и Ext4) и нижележащих LVM и raid много больше. Не экспериментировать же фейсбуку на продакшне. ну и по поводу "сквозной целостности" туда же - критерий теории - практика. Пройдёт ещё года три, опробуют ZFS хорошенько разные энтузиасты, выявятся слабые места и баги - тогда и в серьёзные проекты можно. Как с XFS той же было.
| |
|
5.10, iZEN (ok), 15:48, 27/09/2011 [^] [^^] [^^^] [ответить] | +/– | Тут посчитали http www linux org ru jump-message jsp msgid 4936858 cid 494444... большой текст свёрнут, показать | |
|
6.13, Michael Shigorin (ok), 10:46, 28/09/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Как долго в продакшене LVM2 с Ext4?
LVM много для чего избыточен.
> ZFS была представлена в OpenSolaris в ноябре 2005г., а в Solaris используется
> в продакшене с июня 2006 года — больше 5 лет практического использования.
> У какой из технологий хранения данных больше срок практической эксплуатации?
Вам опять напомнить про приплыв того же joyent (на солярке, а не левой с точки зрения разработчика операционке)? Постеснялись бы хоть.
| |
6.14, Crazy Alex (??), 17:55, 28/09/2011 [^] [^^] [^^^] [ответить]
| +/– |
20% разницы кода по сравнению с десятком, если не больше, лет вылизывания XFS на куче машин - копейки. LVM вообще только совсем уж ленивый не использует, по нему опыта тоже валом.
Кроме "как долго" есть ещё понятие "у скольких людей". Суммарная доля установок bsd и соляриса во сколько раз меньше линукса? В сто? В тысячу? Поэтому хотя ext4 и свежее, она УЖЕ оттестирована лучше. И дальше разница будет только нарастать.
ZFS для линукс есть, как все прекрасно знают. Но пока оно дойдёт до примемлемого уровня надёжности опять-таки пара лет пройдёт.
А "копроэкономика" - это полагаться на систему, которую поддерживает десять человек и полторы фирмы вместо альтернативы, которую клепает весь мир. Тогда на выходе только "копро" и будет.
| |
|
|
|
|
|
1.12, superuser (?), 00:38, 28/09/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
почти по теме, кто-нибудь заморачивался на тему raid1 with ramdisk? те объединяем в софтварный рэйд сверхбыстрый на чтение диск в ОЗУ и обычный накопитель для хранения данных. Например, такое нужно для некоторых файловых баз, размер которых не превышает 4гб.
немного погуглил, но никакой конкретики, везде предлагают купить SSD и не городить костыли.
| |
|
2.15, me (??), 19:12, 28/09/2011 [^] [^^] [^^^] [ответить]
| +/– |
запись в r1 считается завершенной после коммита на все устройства r1, на чтенние это чудо будет быстрым, но pagecahe все равно быстрее (и вам кстати придется писать/читать его O_DIRECT, иначе будет вам двойной оверхед памяти, хотя че там... "память нынче дешевая")
| |
|
3.16, name (??), 19:23, 28/09/2011 [^] [^^] [^^^] [ответить]
| +/– |
Понятно, что pagecahe будет быстрее, но только он не работает с древними базами в виде туевой хучи DBF-файлов.
также понятно, что запись будет с обычной скоростью, но скорость чтения должна вырасти раз в 100.
>"память нынче дешевая"
именно, 4 гига оперативы нынче это уже немного устаревший сервер, а сама файловая база занимает не более этого объема, прирост производительности должен же быть.
| |
|
4.17, me (??), 19:44, 28/09/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Понятно, что pagecahe будет быстрее, но только он не работает с древними базами в виде туевой хучи DBF-файлов.
серьезно? хмм... а я-то думал, ему пофиг какие блоки кэшировать... хоть дидями читай.
| |
4.18, XoRe (ok), 01:16, 29/09/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Понятно, что pagecahe будет быстрее, но только он не работает с древними
> базами в виде туевой хучи DBF-файлов.
> также понятно, что запись будет с обычной скоростью, но скорость чтения должна
> вырасти раз в 100.
Если вы используете современную БД, то, будучи правильно настроенно, она и так держит нужные данные в оперативке.
А если у вас БД, которая работает только на файлах, можно вообще иметь диск только в оперативке.
С rsync раз в минуту на жесткий диск.
| |
|
5.21, Аноним (-), 21:48, 06/10/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> Понятно, что pagecahe будет быстрее, но только он не работает с древними
>> базами в виде туевой хучи DBF-файлов.
>> также понятно, что запись будет с обычной скоростью, но скорость чтения должна
>> вырасти раз в 100.
> Если вы используете современную БД, то, будучи правильно настроенно, она и так
> держит нужные данные в оперативке.
> А если у вас БД, которая работает только на файлах, можно вообще
> иметь диск только в оперативке.
> С rsync раз в минуту на жесткий диск.
Попробуй 1 Тб базу целиком в оперативку засунуть? И - когда сможешь - расскажи о производительности, ага?
| |
|
6.23, XoRe (ok), 16:29, 08/10/2011 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>>> базами в виде туевой хучи DBF-файлов.
>>> также понятно, что запись будет с обычной скоростью, но скорость чтения должна
>>> вырасти раз в 100.
>> Если вы используете современную БД, то, будучи правильно настроенно, она и так
>> держит нужные данные в оперативке.
>> А если у вас БД, которая работает только на файлах, можно вообще
>> иметь диск только в оперативке.
>> С rsync раз в минуту на жесткий диск.
> Попробуй 1 Тб базу целиком в оперативку засунуть? И - когда сможешь
> - расскажи о производительности, ага?
Человек написал:
> Например, такое нужно для некоторых файловых баз, размер которых не превышает 4гб.
Мой совет был только ему.
Чукча не читатель, чукча писатель, да?)
| |
|
|
|
|
2.19, 1 (??), 16:57, 29/09/2011 [^] [^^] [^^^] [ответить]
| +/– |
поставь много памяти и прочитай эти базы разок они будут в кеше системы + можно поискать настройки подшаманить чтоб файловый кэш был поболее и никаких рейдов :)
| |
|
3.22, Аноним (-), 21:49, 06/10/2011 [^] [^^] [^^^] [ответить]
| +/– |
> поставь много памяти и прочитай эти базы разок они будут в кеше
> системы + можно поискать настройки подшаманить чтоб файловый кэш был поболее
> и никаких рейдов :)
И посмотри на скорость базы в пару терабайт целиком в памяти.
| |
|
4.24, XoRe (ok), 16:31, 08/10/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> поставь много памяти и прочитай эти базы разок они будут в кеше
>> системы + можно поискать настройки подшаманить чтоб файловый кэш был поболее
>> и никаких рейдов :)
> И посмотри на скорость базы в пару терабайт целиком в памяти.
Имеете базу в 1 Тб и пытаетесь применять советы для базы в 4 Гб?
Экий вы злобный буратино)
| |
|
|
|
|