Category: Space navigation

Distance to Point, Great Cricle Distance, Cosine Theorem, Haversine formula

By , March 21, 2012 11:07 PM

Great Circle Distance Calculation

http://code.google.com/apis/maps/articles/phpsqlsearch.html

Finding locations nearby with MySQL

To find locations in our markers table that are within a certain radius distance of a given latitude/longitude, you can use a SELECT statement based on the Haversine formula. The Haversine formula is used generally for computing great-circle distances between two pairs of coordinates on a sphere. An in-depth mathemetical explanation is given by Wikipedia and a good discussion of the formula as it relates to programming is on Movable Type’s site.

Here’s the SQL statement that will find the closest 20 locations that are within a radius of 25 miles to the 37, -122 coordinate. It calculates the distance based on the latitude/longitude of that row and the target latitude/longitude, and then asks for only rows where the distance value is less than 25, orders the whole query by distance, and limits it to 20 results. To search by kilometers instead of miles, replace 3959 with 6371.

SELECT id, ( 3959 * acos( cos( radians(37) ) * cos( radians( lat ) ) * cos( radians( lng ) – radians(-122) ) + sin( radians(37) ) * sin( radians( lat ) ) ) ) AS distance FROM markers HAVING distance < 25 ORDER BY distance LIMIT 0 , 20;

 

SELECT ((ACOS(SIN($lat * PI() / 180) * SIN(`lat` * PI() / 180) + COS($lat * PI() / 180) * COS(`lat` * PI() / 180) * COS(($lon – `lon`) * PI() / 180)) * 180 / PI()) * 60 * 1.1515) AS distance FROM `members` HAVING distance<=’10′ ORDER BY distance ASC

 

Necessary reading for Great Circle Distance Calculations

http://code.google.com/apis/maps/articles/phpsqlsearch.html

http://www.movable-type.co.uk/scripts/latlong.html

http://zcentric.com/2010/03/11/calculate-distance-in-mysql-with-latitude-and-longitude/

http://www.scribd.com/doc/2569355/Geo-Distance-Search-with-MySQL

Char and VARCHAR

By , September 5, 2011 8:34 PM

Where the data varies significantly in length from one record to the next with the longest being significantly longer than the average then you need to use a VARCHAR. There is no point in using a CHAR(40) if the average length is only 15 since that will resuult in a lot of wasted space in most records. Using a VARCHAR(40) instead means that you can still fit the leng 40 chharacter values while the average space used will be 15 plus the record length marker overhead.

summary use varchar for variable length fields and use char if you are expecting it to always be the same eg CHAR (ASSS, DASS, FASS, TASS) this is good for a char ie fixed length fields

Moon pics

By , July 23, 2011 4:42 PM

Hi see pics

20110723-013907.jpg

20110723-014011.jpg

20110723-014120.jpg

MYSQL Tuning and Optimizing of my.ini or my.cnf

By , February 25, 2011 8:35 PM

One of the factors with the biggest impact on database performance is not the MySQL settings, but your queries! Make sure you have optimized all your queries first, and have created the right indexes on your tables for MySQL to use.

When tuning MySQL, the two most important variables to configure are key_buffer_size and table_cache. You should first feel confident that you have these set appropriately before trying to optimize any other variables. Ideally, key_buffer_size will be large enough to contain all the indexes (i.e. at least the total size of all .MYI files on the server) of your MyISAM tables.

1. query_cache_size:
* MySQL provides one feature that can prove very handy – a query cache. In a situation where the database has to repeatedly run the same queries on the same data set, returning the same results each time, MySQL can cache the result set, avoiding the overhead of running through the data over and over and is extremely helpful on busy servers.
2. key_buffer_size:
* The value of key_buffer_size is the size of the buffer used with indexes. The larger the buffer, the faster the SQL command will finish and a result will be returned. The rule-of-thumb is to set the key_buffer_size to at least a quarter, but no more than half, of the total amount of memory on the server. Ideally, it will be large enough to contain all the indexes (the total size of all .MYI files on the server).
* A simple way to check the actual performance of the buffer is to examine four additional variables: key_read_requests, key_reads, key_write_requests, and key_writes.
* If you divide the value of key_read by the value of key_reads_requests, the result should be less than 0.01. Also, if you divide the value of key_write by the value of key_writes_requests, the result should be less than 1.
3. table_cache:
* The default is 64. Each time MySQL accesses a table, it places it in the cache. If the system accesses many tables, it is faster to have these in the cache. MySQL, being multi-threaded, may be running many queries on the table at one time, and each of these will open a table. Examine the value of open_tables at peak times. If you find it stays at the same value as your table_cache value, and then the number of opened_tables starts rapidly increasing, you should increase the table_cache if you have enough memory.
4. sort_buffer:
* The sort_buffer is very useful for speeding up myisamchk operations (which is why it is set much higher for that purpose in the default configuration files), but it can also be useful everyday when performing large numbers of sorts.
5. read_rnd_buffer_size:
* The read_rnd_buffer_size is used after a sort, when reading rows in sorted order. If you use many queries with ORDER BY, upping this can improve performance. Remember that, unlike key_buffer_size and table_cache, this buffer is allocated for each thread. This variable was renamed from record_rnd_buffer in MySQL 4.0.3. It defaults to the same size as the read_buffer_size. A rule-of-thumb is to allocate 1KB for each 1MB of memory on the server, for example 1MB on a machine with 1GB memory.
6. thread_cache:
* If you have a busy server that’s getting a lot of quick connections, set your thread cache high enough that the Threads_created value in SHOW STATUS stops increasing. This should take some of the load off of the CPU.
7. tmp_table_size:
* “Created_tmp_disk_tables” are the number of implicit temporary tables on disk created while executing statements and “created_tmp_tables” are memory-based. Obviously it is bad if you have to go to disk instead of memory all the time.

Notes for the future (i.e InnoDB):
If you use InnoDB, it’s buffer pool is controlled by: innodb_buffer_pool_size (this cache also holds row level data). This is the equivalent of key_buffer_size for MyISAM key buffers.
innodb_additional_mem_pool_size
This variable stores the internal data structure. Make sure it is big enough to store data about all your InnoDB tables (you will see warnings in the error log if the server is using OS memory instead).
Since MySQL 4.1.1, the buffer block size is available with the key_cache_block_size server variable. Default 1024.

then test your setup on http://www.omh.cc/mycnf/ to check your max memory size

Mark 8

By , February 1, 2011 10:22 AM

MARK 8
And he called unto him the multitude with his disciples, and said unto them, If any man would come after me, let him deny himself, and take up his cross, and follow me.

For whosoever would save his life shall lose it; and whosoever shall lose his life for my sake and the gospel’s shall save it.

For what doth it profit a man, to gain the whole world, and forfeit his life?

For whosoever shall be ashamed of me and of my words in this adulterous and sinful generation, the Son of man also shall be ashamed of him, when he cometh in the glory of his Father with the holy angels.

Thomas Challenger Thomas Challenger