How much RAM should SQL Server have
Every time you scan a big index (or a big table, if you prefer) that data has to be brought from disk to memory. When this happens, if the buffer pool is holding data from other objects and does not have enough free space to accomodate the pages you are reading from disk, something has to be discarded. 

Low PLE means that this process happens too often, thrashing your buffer pool and overwhelming your I/O subsystem.

Some ways to improve it:


Add more RAM. Easy and not very expensive nowadays. Doesn't really solve the problem, but can be an acceptable short-term solution. How much RAM? Enough to hold the active portion of your databases. Only you can tell how much that is. Not all versions/editions of SQL Server and Windows can use the same amount of RAM, so make sure you're not limited by that.
Purge some data. Are you sure you need all the data you have in
there?
Create smaller indexes. That means including in your indexes the
minimum set of columns that cover your queries. Big scans work
faster on smaller indexes and require less RAM. The tradeoff is more
space used on disk and more operations to perform when updating the
table.
Create filtered indexes. If you are often filtering on a common
non-selective condition (eg: active=true or something similar) a
filtered index might help reducing the size of the indexes. This has
some impact on the application as well (some SET options
restrictions to make it work).
Use compression. Data is compressed both on disk and in memory, so
ROW/PAGE compression can be a way to reduce memory comsumption.
You will need Enterprise Edition and you have to give up some CPU,
but it's often worth it for huge objects.
Use the correct data types: using (n)char over (n)varchar or int when tinyint is enough will waste not only disk space, but also buffer pool space. This includes character and numeric data types: make sure you're using the right type/size/precision/scale for your data columns.