|
Задавайте вопросы, мы ответим
Вы не зашли.
В базе около 500 млн записей. Подскажите, как лучше построить базу?
Неактивен
coop3r написал:
В базе около 500 млн записей. Подскажите, как лучше построить базу?
Базу лучше строить на возвышенности, чтобы как можно с большего расстояния видеть приближение и происки потенциального врага. Хотя в современных условиях ведения войны с активным применением крылатых ракет существенность этого фактора, конечно, снижается. Но ведь при достаточной площади найденной возвышенности можно разметить неплохую ПВО, включая C-300, обзорность которой будет также выше чем в низменности. Так что начните с простого. Когда найдете - приходите с более конкретными вопросами, вместе над ними подумаем.
Неактивен
Виноват...)))
Вобщем планируется работать с большой базой около 500 млн записей...
Будут там поля int(15), int(15), varcha(255), text. В первом int будут уникальные ключи записи. Запрос будет такой (select * from table where id = ... and id2 = ...) Вот вопрос как првильно нужно все это сделать? Сделать 500 млн в одной таблице и на одном сервере. Либо в нескольких таблиц к примеру по 5 млн записей. Или же разместить это все на нескольких серверах? И сколько будет по времени выполняться такой запрос?
Неактивен
Шардирование надо запланировать заранее, разумеется. Конкретные числа можно будет узнать в любом случае только после нагрузочного тестирования.
Неактивен
Исходя из вашего опыта подскажите какое колличество запесей лучше использовать на каждом сервере.
Неактивен
Все зависит от количества машинных ресурсов, которые Вы готовы выделить
под MySQL на каждой конкретно взятой машинке. Обычно я не допускаю, чтобы
количество строк в таблице переваливало за 10 млн — с огромными таблицами
просто не удобно работать. В Вашем случае (500 млн) стоит посмотреть на произ-
водительность вставки при 100 млн и дальше решить, сколько машинок Вам нужно.
Неактивен
paulus, скажите пожалуйста мы можем с вами пообщятся к примеру по icq?
Неактивен
А чем Вам не нравится способ общения на форуме? 
Неактивен
В форуме мне общаться нравиться, но просто тут ситуация такая когда разговор не форуманый... тоесть хотел бы с вами поговорить тет-а-тет.
Неактивен
Возник вопрос по индексам. К примеру у меня есть таблица с полями id, site, account, url, status, cost.
В системе будут ткие запросы:
1. where site = ... and account = ... and status = ...
2. where site = ... and account = ... and url = ...
3. where site = ... and account = ... and cost = ...
Правильно ли будет сделать 3 составных индекса:
(site, account, status)
(site, account, url)
(site, account, cost)
Неактивен
Зависит от CARDINALITY соответствующих полей. В общем случае надо
ставить первым поле, которое выберет минимальное количество строк.
Неактивен
К примеру в табице около 1 млн записей ID - уникальный + индекс, если я удяю какую-нибудь запись индексы перестраиваются? это трудоемкий процесс при млн записей?
Неактивен
Удаление — не трудоемкий процесс. Вставка автоинкрементная — тоже
не очень трудоемкий процесс. Вставить в середину индекса — трудоемкий
процесс.
Неактивен
Нужно разработать быструю надежную и маштабируемую бызу данных! Нужна ваша помошь вы сможете помочь это сделать?
Неактивен
Ну, собственно, я уже написал всё, что нужно — нужно планировать шардирование
и проводить нагрузочное тестирование для оценки скорости работы.
Неактивен
Есть база 100 млн записей. Ко мне в скрипт передаются через массив id полей которые необходимо обновить(UPDATE).
Может передатся сразу и 100 и 5000 значения. Но значения могут быть не верны. Тоесть к примеру передаются значения 1,2,3,4 но данному пользователю принадлежат только 1,3,4 2 - принадлежит не этому пользователю. Обновилоь только 3 записи, Вопрос как лучше сделать обновление такой таблицы(100-5000 записей)? Лучше ли сначала проверить подходит ли полученный id данному пользователю или сразу лучше вставлять все в UPDATE
Неактивен
А как Вы обновите несколько строк одним UPDATE?
Я бы сразу UPDATE делал — одно обращение к таблице при поиске по ключу
и сразу же обновление быстрее сначала поиска, а потом обновления.
Неактивен
paulus написал:
А как Вы обновите несколько строк одним UPDATE?
Я бы сразу UPDATE делал — одно обращение к таблице при поиске по ключу
и сразу же обновление быстрее сначала поиска, а потом обновления.
Тогда такой вопрос к примеру в базе 10 млн записей и мне необходимо обновить 1000 значений. т.е. к примуру на скрипт приходит 1020 id по которым необхрдимо обновить значения в базе. но верных тоесть которые соответствуют условию только 1000 так вот как лучше всего это сделать?и как такая ситуация будет влиять на базу! Спасибо
Неактивен
Вы не ответили на мой вопрос, а на Ваш вопрос я ответил в предыдущем
сообщении 
Неактивен
Ну к примеру какой запрос лучше использовать когда к примеру нужно обновить несколько тыс строк
update ... case when ... in (2,3,4,5,6...) -> ответ на вш вопрос.
или update сделать в цикле и обновлять по одной записи?
Неактивен
Извеняюсь за вмешательство.
Если вопрос что лучше
update ... case when ... in (2,3,4,5,6...) -> ответ на вш вопрос.
...
Намудрили чего-то: "case when"
мало кто делает так: UPDATE (одно и то-же изменение) WHERE ID IN ( 1000 зачений )
потому и спрашивают: "А как Вы обновите несколько строк одним UPDATE?"
Неактивен
Значения то разные.
update pages set url = case when id = 1 then ttt when id = 2 then eee ... where id in (1,2...)
Неактивен
неужели все url разные? если все разные, то разные и запросы будут. а вот если не все url разные, то попробуйте в начале найти те url которые одинаковые, а уже потом делать update на несколько id, у которых одинаковый url.
и еще один момент, если вам всегда на вход передают url в чистом виде и вы никогда не ищете по подстроке в столбце с url, то лучше хранить хеш url, а не сам url. я так думаю, что url у вас хранится в text, а это влечет большие расходы при длинных значениях.
Неактивен
