- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Добрый день
Прошу совета знатоков.
Сейчас есть база mysql в ней хранятся данные о географических точках (то есть поля две цифры + служебные поля принадлежности к объекту). Но этих точек очень много (несколько миллионов) и по мере роста базы все стало тормозить, так как mysql не справляется и съедает большую часть ресурсов. Данные обновляются редко, в основном происходит только добавление новых.
обращений к базе не много (это служебная информация, по которой строятся элементы), то есть по сути никаких множественных обращений не происходит.
Вопрос: как организовать хранение этих данных? если например хранить это все дело в файлах, побив объекты на группы, даст это прирост в скорости доступа?
Раньше не сталкивался с хранением таких больших объемов данных, поэтому буду благодарен за советы, в какую сторону смотреть для поиска решения.
Лучше данные хранить в базе SQL. Так как это удобно и не факт, что на файлах своего формата будет быстрее.
Используются ли правильно индексы в таблицах и запросах?
Если с индексами все нормально, но все равно тормозит, значит нужно делать репликацию базы данных.
То есть один мастер сервер, в который заносим данные, и несколько Slave серверов в которые данных автоматически переносятся системой репликации.
Запросы Select можно делать к Slave серверам. Это позволит распараллелить запросы на несколько серверов.
Для начала я бы взял мощьный сервер и попробовал поставить на него. Может и один сервер справится при условии правильной индексации.
Добрый день
Прошу совета знатоков.
Сейчас есть база mysql в ней хранятся данные о географических точках (то есть поля две цифры + служебные поля принадлежности к объекту). Но этих точек очень много (несколько миллионов) и по мере роста базы все стало тормозить, так как mysql не справляется и съедает большую часть ресурсов. Данные обновляются редко, в основном происходит только добавление новых.
обращений к базе не много (это служебная информация, по которой строятся элементы), то есть по сути никаких множественных обращений не происходит.
Вопрос: как организовать хранение этих данных? если например хранить это все дело в файлах, побив объекты на группы, даст это прирост в скорости доступа?
Раньше не сталкивался с хранением таких больших объемов данных, поэтому буду благодарен за советы, в какую сторону смотреть для поиска решения.
Вы бы описали структуру базы данных, какой тип полей, индексы.
Структуру таблиц(ы) покажите, какое число данных в базе, какое железо на сервере, конфиг базы меняли или оставили дефолтным ?
оптимизировать структуру БД.
Несколько миллионов точек - это не много. Надо смотреть на то, какие запросы Вам нужны и либо править запросы, либо править индексы. При некоторых типах запросов будет проще поставить postgres или использовать геонадстройку к mysql (если это поделие можно вообще использовать), но для обработки именно геоточек это всё лишнее.
самое-самое это база данных SQL
Вопрос: как организовать хранение этих данных? если например хранить это все дело в файлах, побив объекты на группы, даст это прирост в скорости доступа?
можно применить математические алгоритмы...
есть различные решения почти "из коробки", так же Berkeley DB и NoSQL
можно применить математические алгоритмы...
Интересно, а реляционные базы данных - это не "математические алгоритмы"? :) Но звучит солидно: "ща как применим математические алгоритмы..."
есть различные решения почти "из коробки", так же Berkeley DB и NoSQL
Решения чего? Проблемы, которой толком и не сформулировали?
memcached ещё никто не порекомендовал?
1) Explain тормознутых запросов нужен,
2) Структуры таблицы