Ну Моторов я бы в пример не ставил. Они всегда были на рынок vendor-customized телефонов заточены. Мне кажется только кризис 8 го года и мог их оттуда выбить. При этом для Гугла они там и не были бы «угрозой»: у каждого своя песочница, и свои контент провайдеры. Вообщем они неагрессивны по отношению друг к другу.
Потом Motorola-Mobile в разработке именно телефона, а не «маленького планшета по которому можно еще и звонить» это совсем другая лига. К сожалению Была. Видимо эра мобильников проходит, и нам таки придется звонить по мини-планшетникам.
Странно. Вроде бы только «поперло» и тут же уходить?
Для меня Андроид прочно ассоциируется с Самсунгом. Нет конечно есть и китайцы и HTC и прочие. Но как то прочно в голове сидит: нормальный поддерживающийся и обновляющийся софт — «на базе Android» качественное железо/дизайн — Самсунг. Отсюда супруге взял S3. В качестве альтернативы только iPhone, да и то только ради понтов.
Себе таки закажу или китайца или тоже что нибудь из S3 или что там будет к тому времени. Опять же в первую очередь Андроид, и уже под него железо. Брать смартфон на нестандартной платформе типа Бады — не знаю. Ясно же что в ближайшее время все будут на iOS, Android и Win8. И опять свои AppStore… Ну вот у меня самсунговский смарт тв со своим какимто аппстором. Бесплатного раз два и обчелся, путного пусть и платного, еще меньше. Ну и смысл?
Прошивка в смысле смарт тв глючная. тормознутная и не проработанная. И вот зачем мне такой же телефон?
Не буду советовать за EnterpriseDB. Его самый большой плюс это коммерческие консультации/поддержка/ Практически все гуру PG «живут» им. По чистой скорости работы, некоторые оптимизации конечно есть, но не ключевые. А насчет Оракловых хранимок в PG ощущение двоякое. Видел я код для PG писаный Оракловцем. Спасибо не надо. Просто некоторые вещи с постгрессе сделаны совсем не так как в оракле. И использующий, например вьюшки для оптимизации времени исполнения программер оракла не может даже представить что в постгрессе они ни коим образом не материализуются, совсем. И мест таких достаточно. Так что бездумно код переносить не стоит.
Но конечно ODBC более «взрослый» что ли.
Но повторюсь: какой то принципиальной разницы, особенно в использовании диска, не будет. Ребята из Enterprise DB вроде более менее честные и свои концептуальные изменения бекпортят в основной Постгрес.
Ну в целом серьезные SSD накопители заявляют до нескольких петабайт записи. Если пишем терр в сутки то на пару лет должно хватить :) Опять же многомного памяти, длинные чекпоинты и еще подольше. Мы тут прикидывали — разница по стоимости HDD 10к/SSD порядка 10 раз. А по производительности от 3х до 10х. Там проблема встаеть уже в 6G интерфейсе. Приходится PCIE думать а тут уже с горячей заменой сложности.
Но в целом думаю за SSD будущее СУБД. Да и последний HighLoad. Все у кого более менее серьезное чтото, где требуется хоть какаято надежность (всякие фейсбуки не в счет). Так или иначе — реляционки + флеш, у кого под хранение, у кого под кеш.
>Вопрос такой, как это «все» попадало в кэш, если база больше оперативы в 5 раз и чтение/запись осуществляется из >случайных участков базы… по моему так кэш постоянно перемешивается, не?
Все не попадало, данные пишутся более менее равномерно, есть шанс что эффекетивно работает prefetch и поднимает данные для следующего запроса в кеш.и он в итоге так «окошком» и идет. Кстати легко проверить: при работе запросов на выборку в цикле дропать кеш :) по вашей теории это не будет влиять ибо все равно все перемешено и идет мимо кеша.
>>>> Может у вас первые полчаса
>> Ну это гипотеза, предполагать можно что угодно.
Вот и iostat помог бы подтвердить или опровергнуть.
Я вообще склонен к большому числу тестов кратковременных. например не два часа теста и среднее, а последовательно подряд 24 теста по 5 минут. заодно и увидим равномерно ли, если ли пики, насколько они существенны/незначительны, меняется ли со временем.
Ну и вторая склоннось — обложить все различными логами от iostat до top и поотм искать корреляции. А то мало ли ext4 быстрее но отжирает 100% CPU. У меня вот прямо сейчас под постгрессом UPDATE одной записи в табличке из 5 записей общим размером меньше 10 килобайт занимает 62 минуты. А все потому что fs фрагментировано свободное пространство и любой чих с файловой системой приводит к 95%sys на полчаса. (кстати xfs забитая на 95%)
Если бы disk util был 100% не было бы >100 tps. iostat бы показал что работа действительно ведется с диском а значит и с файловой системой, а не с shared_buffers (что весомо особенно при значительном числе клиентов) и не с кешем операционной системы. Что тест реально гоняет файловую систему, а не обращается последовательно по таблице от начало до конца в пределах размера кеша. Задержки покажут что действительно работаем, а не читаем из кеша контроллера и т.д.
Опять таки размещая WAL вместе с данными замазали почти все что различно у файловых систем. и преалокацию, и работу с sync. Вот даже по вашему тесту вы уверенны что скорость работы ограничивалась именно доступом к файлам таблиц, а не с коммитом WAL. Особенно в тестах TPC-B. Средняя скорость транзакций 100tps в течении двух часов это неинтересно. Может у вас первые полчаса было под 20-30 тысяч а остальные полтора часа менее 10. (Пока индексы помещаются в shared_buffers скорость вставки может быть и 40k/s а потом ррраз и резко 2-3 записи).
Вообще ни о чем.
1. Настройки постгреса? Например размер shared_buffers?
2. Записи нет совсем. Точнее не показательна
3. Лог iostat?
4. Размер кеша контролера/размер оперативки по отношению к размеру БД/индексов.
Вывод конечно правильный, практика показывает что PostgreSQL достаточно эффективно работает с файловыми системами (с ext2 он будет работать еще быстрее :) ). Но эта же практика показывает что если БД не помещается в оперативу хороших скоростей ФС не обеспечит. Но я склонен считать что во время вашего тестирования все попадало в кэш. Ибо примерно теже цифры мы получали на 380 G7, на обычном SATA2 7200 причем они были одинаковы с SSD шным диком (чиста бытовым интелом), но с достаточным количеством озу. Ровно до тех пор пока озу не заканчивалось. И вот тогда начинали работать диски, рос %util в iostat и tps упало до нескольких десятков на HDD и почти не изменилось на SSD. Вот в этих режимах (однозначно не штатных) и интересно посмотреть на сравнение систем.
В науке ценны идеи. Даже ложные. Если посмотреть критически, то можно так и к Эйнштейну подойти, и к Ньютону, и к Ниццше, а Архимед с Аристотелем вообще шарлатанами окажутся.
Хоккинг — это генератор идей, причем не бредовых и абсурдных, а теоретически возможных. Таких, что уйма ученых пытаются их опровергнуть или подтвердить.
Может быть эти идеи и опровергнуты, но сколько новых открытий, технологий, теорий было построено в попытках опровергнуть Хоккинга?
Теперь моральный долг Ахмета (ессно скрываясь за прокси) продавать свои услуги бывшим коллегам студентам зная об уязвимости ибо там наверняка есть еще подобные. А вообще конечно глупо.
По нескольким причинам:
1. он вырезан из нашей версии дистрибутива
2. комплекс работает автономно от сети интернет и доставить пакеты — нетривиальная задача, поэтому пользуемся чем есть.
3. установить и настроить, а потом забрать данные под графики из rrdtool не легче чем просто взять логи iostat
Ну и самая главная причина: gnuplot и iostat были, и был опыт их использования. А rrdtool не было, и что бы его заставить работать надо было маны покурить, к гуглу сходить. В условиях жесткого цейтнота принцип: лучше день потерять и потом за час долететь — не подходит :)
З.Ы. Да я знаю, что лучше иметь систему постоянного наблюдения, что нибудь на основе какого нибудь заббикса. Но законы Мерфи всесильны, и там где она есть — ниче не происходит, а вот где нет сроду какая нибудь уличная магия твориться.
ХМ, подождем :) Любил элиту еще со спетрумских времен. Серия X2/X3 конечно неплоха, но ограниченность мира и действий удручала. Да и проработка никакая. Пришлось даже шрифты свои рисовать для X2. Надеюсь с этим Брэбен не подкачает.
Я бы сказал в военных вузах «кучность» больше. Из них выходят специалисты среднего уровня подготовки, качество преподавания среднее.
А вот в гражданских — у кого цель научиться — научится и его качество будет выше, просто потому что преподавателей хорошего качества много. Возможность «колымить» по специальности забивая на непрофильную учебу и т.п. Вот только да наличие в гражданских вузах раздолбаев превышает число «ботанов» и в итоге среднее по больнице удручает.
Именно так и делаем. Ибо await и iops вещи практически неразделимые. Хотя бы потому что 1500 iops у SSD диска совсем не 10 раз быстрее чем 150 iops у HDD если учесть что у первого await <2 а у второго >200
Потом Motorola-Mobile в разработке именно телефона, а не «маленького планшета по которому можно еще и звонить» это совсем другая лига. К сожалению Была. Видимо эра мобильников проходит, и нам таки придется звонить по мини-планшетникам.
Для меня Андроид прочно ассоциируется с Самсунгом. Нет конечно есть и китайцы и HTC и прочие. Но как то прочно в голове сидит: нормальный поддерживающийся и обновляющийся софт — «на базе Android» качественное железо/дизайн — Самсунг. Отсюда супруге взял S3. В качестве альтернативы только iPhone, да и то только ради понтов.
Себе таки закажу или китайца или тоже что нибудь из S3 или что там будет к тому времени. Опять же в первую очередь Андроид, и уже под него железо. Брать смартфон на нестандартной платформе типа Бады — не знаю. Ясно же что в ближайшее время все будут на iOS, Android и Win8. И опять свои AppStore… Ну вот у меня самсунговский смарт тв со своим какимто аппстором. Бесплатного раз два и обчелся, путного пусть и платного, еще меньше. Ну и смысл?
Прошивка в смысле смарт тв глючная. тормознутная и не проработанная. И вот зачем мне такой же телефон?
Но конечно ODBC более «взрослый» что ли.
Но повторюсь: какой то принципиальной разницы, особенно в использовании диска, не будет. Ребята из Enterprise DB вроде более менее честные и свои концептуальные изменения бекпортят в основной Постгрес.
Но в целом думаю за SSD будущее СУБД. Да и последний HighLoad. Все у кого более менее серьезное чтото, где требуется хоть какаято надежность (всякие фейсбуки не в счет). Так или иначе — реляционки + флеш, у кого под хранение, у кого под кеш.
Все не попадало, данные пишутся более менее равномерно, есть шанс что эффекетивно работает prefetch и поднимает данные для следующего запроса в кеш.и он в итоге так «окошком» и идет. Кстати легко проверить: при работе запросов на выборку в цикле дропать кеш :) по вашей теории это не будет влиять ибо все равно все перемешено и идет мимо кеша.
>> Ну это гипотеза, предполагать можно что угодно.
Вот и iostat помог бы подтвердить или опровергнуть.
Я вообще склонен к большому числу тестов кратковременных. например не два часа теста и среднее, а последовательно подряд 24 теста по 5 минут. заодно и увидим равномерно ли, если ли пики, насколько они существенны/незначительны, меняется ли со временем.
Ну и вторая склоннось — обложить все различными логами от iostat до top и поотм искать корреляции. А то мало ли ext4 быстрее но отжирает 100% CPU. У меня вот прямо сейчас под постгрессом UPDATE одной записи в табличке из 5 записей общим размером меньше 10 килобайт занимает 62 минуты. А все потому что fs фрагментировано свободное пространство и любой чих с файловой системой приводит к 95%sys на полчаса. (кстати xfs забитая на 95%)
Опять таки размещая WAL вместе с данными замазали почти все что различно у файловых систем. и преалокацию, и работу с sync. Вот даже по вашему тесту вы уверенны что скорость работы ограничивалась именно доступом к файлам таблиц, а не с коммитом WAL. Особенно в тестах TPC-B. Средняя скорость транзакций 100tps в течении двух часов это неинтересно. Может у вас первые полчаса было под 20-30 тысяч а остальные полтора часа менее 10. (Пока индексы помещаются в shared_buffers скорость вставки может быть и 40k/s а потом ррраз и резко 2-3 записи).
1. Настройки постгреса? Например размер shared_buffers?
2. Записи нет совсем. Точнее не показательна
3. Лог iostat?
4. Размер кеша контролера/размер оперативки по отношению к размеру БД/индексов.
Вывод конечно правильный, практика показывает что PostgreSQL достаточно эффективно работает с файловыми системами (с ext2 он будет работать еще быстрее :) ). Но эта же практика показывает что если БД не помещается в оперативу хороших скоростей ФС не обеспечит. Но я склонен считать что во время вашего тестирования все попадало в кэш. Ибо примерно теже цифры мы получали на 380 G7, на обычном SATA2 7200 причем они были одинаковы с SSD шным диком (чиста бытовым интелом), но с достаточным количеством озу. Ровно до тех пор пока озу не заканчивалось. И вот тогда начинали работать диски, рос %util в iostat и tps упало до нескольких десятков на HDD и почти не изменилось на SSD. Вот в этих режимах (однозначно не штатных) и интересно посмотреть на сравнение систем.
Хоккинг — это генератор идей, причем не бредовых и абсурдных, а теоретически возможных. Таких, что уйма ученых пытаются их опровергнуть или подтвердить.
Может быть эти идеи и опровергнуты, но сколько новых открытий, технологий, теорий было построено в попытках опровергнуть Хоккинга?
1. он вырезан из нашей версии дистрибутива
2. комплекс работает автономно от сети интернет и доставить пакеты — нетривиальная задача, поэтому пользуемся чем есть.
3. установить и настроить, а потом забрать данные под графики из rrdtool не легче чем просто взять логи iostat
Ну и самая главная причина: gnuplot и iostat были, и был опыт их использования. А rrdtool не было, и что бы его заставить работать надо было маны покурить, к гуглу сходить. В условиях жесткого цейтнота принцип: лучше день потерять и потом за час долететь — не подходит :)
З.Ы. Да я знаю, что лучше иметь систему постоянного наблюдения, что нибудь на основе какого нибудь заббикса. Но законы Мерфи всесильны, и там где она есть — ниче не происходит, а вот где нет сроду какая нибудь уличная магия твориться.
З.Ы.Ы. И да спасибо — пошел покурю rrdtool
А вот в гражданских — у кого цель научиться — научится и его качество будет выше, просто потому что преподавателей хорошего качества много. Возможность «колымить» по специальности забивая на непрофильную учебу и т.п. Вот только да наличие в гражданских вузах раздолбаев превышает число «ботанов» и в итоге среднее по больнице удручает.