| 
 
 С нами с 24.10.04
 Сообщения: 18881
 Рейтинг: 9010
 
 
 
             
   | 
								
									|  Добавлено: 14/11/12 в 10:06 |  
 
							есть куча папок с картинками, вида /2012/11/14/001/img1.jpg
 
хотелось бы их отдавать через урл вида /123456789.jpg
 
для этого надо хранить ссылки вида 123456789.jpg на папку вида /2012/11/14/001/img1.jpg
 
сейчас это работает через mysql, все вроде бы нормально, нагрузка дошла до 100-200 запросов в сек, но как только на сервере начинают работать кроны по другим запросам к базе, начинаются тормоза    
есть ли какой специальный сервер для этого?
 
возможно есть хитрая надстройка для nginx со своей базой хранения хэшей физ путей? | 
					
						|  |  | 
					
						|  | 
					
						| 
 
 С нами с 11.10.12
 Сообщения: 428
 Рейтинг: 1032
 
 
 
   
   | 
								
									|  Добавлено: 14/11/12 в 12:55 |  
 
							Зачем придумывать дополнительную нагрузку?
Сделай не /123456789.jpg а /20121114001-img1.jpg. Разбор входящих uri - простым, ОДНИМ, rewrite
 | 
					
						|  | 
								
									| 
											apache, bash, css, elasticsearch, ffmpeg, html, js, mysql, mongo, nginx, php; *nix only
										 | 9 |  | 
					
						|  | 
					
						| 
 
 С нами с 24.10.04
 Сообщения: 18881
 Рейтинг: 9010
 
 
 
             
   | 
								
									|  Добавлено: 14/11/12 в 13:10 |  
 
							  | johndoe2 писал: |   | Зачем придумывать дополнительную нагрузку? Сделай не /123456789.jpg а /20121114001-img1.jpg. Разбор входящих uri - простым, ОДНИМ, rewrite
 | 
 
изначально был такой вариант, а потом потребовалось расширения кол-ва функций, типа поиск по размеру файла, кол-ва обращений к нему, рефереров и т.д., без базы тут не обойтись
 
к тому же хранится хитрый хэш картинки, который проверяется при загрузке, и две одинаковые пиксы ссылаются на один физ файл | 
					
						|  |  | 
					
						|  | 
					
						| 
 
 С нами с 11.10.12
 Сообщения: 428
 Рейтинг: 1032
 
 
 
   
   | 
								
									|  Добавлено: 14/11/12 в 13:17 |  
 
							А в сторону redis/memcached вместо mysql смотрели? Или их возможности не подходят под "потребовалось расширения кол-ва функций"?
							 | 
					
						|  | 
								
									| 
											apache, bash, css, elasticsearch, ffmpeg, html, js, mysql, mongo, nginx, php; *nix only
										 | 8 |  | 
					
						|  | 
					
						| 
 
 С нами с 24.10.04
 Сообщения: 18881
 Рейтинг: 9010
 
 
 
             
   | 
								
									|  Добавлено: 14/11/12 в 13:29 |  
 
							memcached тут не подойдет, а к redis присматриваемся, спасибо за идеи!
							 | 
					
						|  |  | 
					
						|  | 
					
						| 
 
 С нами с 11.10.12
 Сообщения: 428
 Рейтинг: 1032
 
 
 
   
   | 
								
									|  Добавлено: 14/11/12 в 13:35 |  
 
							Еще мысль: часть работы может быть можно перенести на обычные логи веб-сервера, если по реферерам и кол-ву обращений данные в базе просто собираются. Если по кол-ву обращений нужно принимать какие-то решения на лету, можно эти решения основывать на данных, которые генерить обработкой логов через крон каждые полчаса например.
 
Нормальные герои всегда идут в обход      | 
					
						|  | 
								
									| 
											apache, bash, css, elasticsearch, ffmpeg, html, js, mysql, mongo, nginx, php; *nix only
										 | 9 |  | 
					
						|  |