* В определении партиций точно стоят CHECK на ВСЕХ партициях?
* Интервалы указанные в CHECK точно НЕ пересекаются? Это частая проблема, когда используют BETWEEN и границы автоматически включены в обе соседние таблицы.
Ну и как бонус, вдруг кому-то пригодится: небольшой Partitioning триггер, который создаёт партиции автоматически, если её еще не существует при вставке в мастер таблицу.
1GB? Какая же у Вас большая оперативка… или как же мал Ваш пул запросов. :)
КАЖДЫЙ процесс/запрос может резервировать данное количество памяти для работы (+на самом деле в запросе могут параллельные операции, которые каждая может выделять по work_mem памяти).
А может быть это связано со значением в work_mem (которое всего 1M по умолчанию)? У меня когда-то была подобная проблема, когда планировщик менял план в корне, из-за того, что не мог уместить нужные данные в память. И проявлялось именно при изменении критериев фильтрации.
Вы посмотрите код. Что там специального для Дейкстры? Только получение следующих нод из текущей, связанных отношением (отношение – «дорога» в данном случае). Естественно для этого пользовались функциями Neo4J.
Опять же, 1-2 года назад были несколько файликов, которые хранили отдельно ноды, атрибутику, связи + Lucene, который индексировал всё что скажете и делал полнотекстный поиск. Легче всего взять примерчик и запустить это дело у себя — он создаст штук 10 файликов — там по названиям всё в общем-то понятно было.
Запросы, естественно. Алгоритмы можно переписать — это не проблема. Сравнивали обычную Дейкстру на двух разных БД. Более того общались напрямую с Peter Neubauer и, к сожалению, даже после их рекомендаций скорость оставалась неприемлимой.
Ограничение Google Shopping по странам никак не связано с Google Checkout. Да и продажи вы вольны производить через любую систему, не только через Google Checkout. Google Shopping лишь помогает пользователю найти товар, сравнить цены и перейти на ваш сайт. Что именно Вы будете делать на нём с данным пользователем — забота Вашего магазина.
Ну и ктстати, комментарий к оригинальной статье (моя попытка перевода ниже):
Jan 17, 2012
Tom Hughes said…
As the person who (in my role as an OpenStreetMap system administrator) first discovered this `incident' let me start by saying that I consider this post to be grossly irresponsible and wholly inappropriate.
The board of OSMF are making mountains out of tiny pimples here. It seems that they want this to be some sort of organised corporate malfeasance on the part of Google which is why they have tried to link it to the recent Mocality incident where there was indeed clear evidence of such behaviour.
The reality in this case is that there is no evidence that this is any different to the numerous other incidents we get all the time where users either accidentally or deliberately make bogus edits. The only difference in this case is that there happen to be two accounts (though we do not know if that is two people) and the user or users involved happen to (presumably) work for Google.
That is the sum total of what we know, and on the back of that, and without approaching Google at all, two leading board members have decided to reveal personal information about two of our users.
It seems to me that this is just an attempt to get some cheap publicity by trying to like the project to the Mocality incident, and I cannot support such behaviour.
Jan 17, 2012
Tom Hughes сказал…
Как человек, который обнаружил (а я системный администратор OpenStreetMap) этот «инцидент», позвольте мне начать с того, что данная статья абсолютно некорректна и безответственна.
Комитет OSMF (OSM Foundation) делает слона из малюсенькой мухи. Они хотят представить его (инцидент), как некоторое организованное, корпоративное преступление Google и именно поэтому связали его с недавним проишествием Mocality, где действительно есть четкие подтверждения такого поведения.
Реальность в здесь такова, что нет доказательств, что это нечто отличающееся от бесчисленного множества других случаев, где пользователи случайно или умышленно делают плохие правки. Единственное отличие данного случая в том, что было 2 учетных записи (хотя не ясно было ли 2 человека) и пользователь или пользователи (предположительно) работали в Google.
Это полное резюме того, что мы знаем и, основываясь на этом, и без нотификации Google вообще, два ведущих (главных?) члена комитета (OSMF) решили раскрыть персональную информацию двух наших пользователей.
Мне кажется, что это просто попытка получить дешевую огласку, пытаясь быть похожими на Mocality, и я не могу поддержать такое поведение.
Во-первых, в оригинале "102 thousand hits", а не «случаев доступа», даже если предположить, что считали только правки, а не запросы на чтение (в чем я собственно сомневаюсь), то переместив всего одну дорогу — вы можете изнемить сотни объектов в ОСМ.
А чтоб побаловаться люди тратят иногда по несколько часов, изучая и играясь в редакторе. Так что 102 тысячи хитов — это совершенные мелочи.
В комментарии на который я отвечал было 2 вопроса: один касался сохранности, второй размеров БД. Само по себе партицирование не гарантирует сохранность данных, а увеличивает пропускную способность.
Тем не менее, есть механизм, позволяющий увеличить сохранность, учитывая кластерную структуру, как уже написали здесь.
* Интервалы указанные в CHECK точно НЕ пересекаются? Это частая проблема, когда используют BETWEEN и границы автоматически включены в обе соседние таблицы.
Ну и как бонус, вдруг кому-то пригодится: небольшой Partitioning триггер, который создаёт партиции автоматически, если её еще не существует при вставке в мастер таблицу.
КАЖДЫЙ процесс/запрос может резервировать данное количество памяти для работы (+на самом деле в запросе могут параллельные операции, которые каждая может выделять по work_mem памяти).
Просто есть модуль Neo4j Spatial, к которому дописали код, позволяющий быстро импортировать OSM данные.
Jan 17, 2012
Tom Hughes сказал…
Как человек, который обнаружил (а я системный администратор OpenStreetMap) этот «инцидент», позвольте мне начать с того, что данная статья абсолютно некорректна и безответственна.
Комитет OSMF (OSM Foundation) делает слона из малюсенькой мухи. Они хотят представить его (инцидент), как некоторое организованное, корпоративное преступление Google и именно поэтому связали его с недавним проишествием Mocality, где действительно есть четкие подтверждения такого поведения.
Реальность в здесь такова, что нет доказательств, что это нечто отличающееся от бесчисленного множества других случаев, где пользователи случайно или умышленно делают плохие правки. Единственное отличие данного случая в том, что было 2 учетных записи (хотя не ясно было ли 2 человека) и пользователь или пользователи (предположительно) работали в Google.
Это полное резюме того, что мы знаем и, основываясь на этом, и без нотификации Google вообще, два ведущих (главных?) члена комитета (OSMF) решили раскрыть персональную информацию двух наших пользователей.
Мне кажется, что это просто попытка получить дешевую огласку, пытаясь быть похожими на Mocality, и я не могу поддержать такое поведение.
А чтоб побаловаться люди тратят иногда по несколько часов, изучая и играясь в редакторе. Так что 102 тысячи хитов — это совершенные мелочи.
И еще несколько мелких, но очень нужных приложений.
С другой стороны у меня уже около года именно 64-битный линукс — полёт нормальный.
Да и специфика налицо: поддеревья по префиксу далеко не любая структура выдаст быстро. Так что использование памяти компенсируется.
Тем не менее, есть механизм, позволяющий увеличить сохранность, учитывая кластерную структуру, как уже написали здесь.